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2000-0474D; AWS527D 
APP(5) 

A SYSTEM AND METHOD FOR PERFORMING THROTTLE 
CONTROL IN A SMPP GATEWAY 

CROSS-REFERENCE TO RELATED APPLICATIONS 

The present application is related to U.S. Application No., , entitled "A 

5 SMPP GATEWAY HAVING A STANDARD JNTERFACE" (Attorney Docket 2000- 

0474 (AWS527)), Application No. , entitled "A METHOD OF 

DELIVERING SHORT MESSAGES USING A SMPP GATEWAY WTIH 
STANDARD INTERFACE;'' (Attorney Docket 2000-0474A (AWS527A)), Application 

No. , entitled «A METHOD OF BINDING TO A SMPP GATEWAY" 

10 (Attorney Docket 2000-0474B (AWS527B)), Application No. , entitled "A 

SYSTEM AND METHOD FOR PERFORMING ANTI-SPAM CONTROL USE^G 
A SMPP GATEWAY" (Attorney Docket 2000-0474C (AWS527C)), and Application 

No. , entided "A SYSTEM AND METHOD FOR PERFORMING FLOW 

CONTROL IN A SMPP GATEWAY" (Attorney Docket 2000-0474E (AWS527E)). 
1 5 Each of these applications is concurrent^ filed and commonly owned. The contents of 
each of these applications are incorporated herein by reference. 

BACKGROUND OF THE INVENTION 

1 . Field of the Invention 
20 The present invention relates to a gateway for delivering messages from a 

message source to wireless devices and, more specifically, to a short mess^e point-to- 
point protocol gateway that performs a throtde control function associated with routing 
messages from an ejctemal source to a wireless device. 
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2. Discussion of Related Art 

Wireless devices such as mobile telephones and the like can transmit and receive 
short messages from a variety of different sources. One example of a source of a short 

5 message destined for a wireless device is a short message entity (SME). Examples of 
such short message entities include computers, interactive voice response systems (IVR), 
teleservice servers, and intelligent peripherals. Examples of short messages that may be 
sent include voice mail and email, A device operating as a message source external to a 
wireless network is commonly called an external short message entity (ESME), 

10 Typically, and in the context of this disclosure, an ESME is a device associated with a 

wired network that operates as a message source delivering a message to a mobile device. 
ESME messages destined for mobile devices are called herein mobile terminated (MT) 
messages since they originate from a wired ESME device and terminate with a mobile 
device. The following discussion relates primarily to MT messages. 

15 In addition to operating as the source for a short message, ESMEs may also 

receive short messages from other devices, such as mobile devices. In this regard, 
messages originating from mobile de\dces are referred to herein as mobile originating 
(MO) messages. 

A basic protocol for delivering messages from a wired network using a teleservice 
20 server to a wireless or mobile device is called the short message peer-to-peer (or point-to- 
point) protocol (SMPP). In addition to this basic protocol that may be used for a variety 
of ESMEs, the exact message flows from the ESME to the mobile device varies for each 
telesendce provider. A basic network architecture by which a message is delivered from 
a message source to a message-receiving device is shown in FIG. 1. As discussed below, 
25 numerous logical interfaces are presentiy necessary between an ESME and a wireless 

network in order to send and receive short messages. The different logical interfaces are 
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necessar}^ because numerous teleservices associated with ESMEs require different 
protocols for interfacing their ESME with routers in order to deUver xht messages. 

The architecture shown in FIG. 1 illustrates a system for delivering short 
messages from an ESME to a wireless network device. An external short messaging 
5 entity 108, 110, 112, 1 14 or 102 is the source of a short message. Examples of an ESME 
may include the telephone, cellular phone, computer connecting through the Internet 
106 to a network, or the like. A plurality of messaging (or message) centers 124^ - 124, 
(MCs) each receives messages from one of the ESMEs. Since diere are many different 
protocols for communicting short messages to die messaging centers, each messaging 
10 center can only receive messages sent by ESMEs 102 delivering messages according to a 
known protocol for that messaging center. If die destination of die ESME 102 message 
is a wireless de\dce, the MCs 124^ - 124^ transmit die short messages to a wireless 
network having network nodes and network switching centers 128, 130, The wireless 
network includes a home location register 126, a mobile switching center 132 and 
15 antennas in order to deliver die message using die over-die-air interface. The mobile 
receiving device, or wireless device 136, receives and displays die intended message to a 
user. 

As the demand for messaging services increases, die number of messages 
delivered by message centers will also increase. The increased demand poses difficulties 
20 in scaling die message complex to handle numerous ESME requests, Furdiermore, non- 
standard ESMEs or ESMEs diat do not recognize a messaging protocol for a phone 
number or pager number may be die intended destinations or message sources for a 
message. This increases the complexity of the network requirements for delivering 
messages. 

25 Having discussed MT messaging, we now turn to a discussion of messages that 

originate from a mobile device. These are referred to herein as mobile originated (MO) 
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messages. Delivering MO messages, like MT messages, suffers from the probem 
discussed above wherein numerous interfaces are necessary for the variet}^ of protocols 
used for the numerous teleservTices. MO messages are transmitted from the mobile 
device through the wireless network to an MC 124^ - 124^. However, each mobile 
5 device transmits messages to its associated MC 124^ - 124^, wherein routing tables or a 
translation process are needed to route the message in the direction of the destination 
ESME. Many different messaging interfaces are necessary for transmitting the message 
from the MC 124^ - 124^ to an ESME 102. The translation processes and need for 
knowledge of a variety of message types slows down the transmission of the message and 

10 the ultimate message delivery time. 

Currendy, throttle control is rarely performed for SMPP messages, although the 
SMPP standard protocol provides for the throtde foncrion but describes no 
implementation. The throtde control presendy used, if any, is based on the total 
message flow. The present throtde control monitors the sum of all messages arriving at 

15 the MC from all ESMEs and determines if that sum exceeds a predetermined limit 

When the throtde control limit is reached, a throtde control message is transmitted to all 
the ESME's to reduce the messages sent. 

There are deficiencies in the present method of performing throtde control. For 
example, it is unfairly governed. If a single ESME transmits so many messages that 

20 throtde control is necessar}% other ESMEs bound to the system will receive a throtde 

error signal preventing them from transmitting messages where the neighboring ESME is 
the one clogging the system. This imnecessarily inhibits messages from being sent by 
ESMEs who are not transmitting messages. 
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SUMMARY OF THE INVENTION 

What is needed in die art is a single logical interface to the messaging complex 
with a fair and efficient throttie control. The single logical interface to the messaging 
complex according to the present invention is called a short messaging point-to-point 

5 (SMPP) gateway (SG) and will provide one consistent interface for ESMEs to request 
delivery of service. ESMEs will also be isolated from any knowledge of the imderlying 
messaging complex or wireless network implementation. With this implementation of a 
standard interface, non-standard ESME's may be allowed to connect to a messaging 
complex and transmit short messages. 

10 In addition, what is needed in the art is a fair and equitable throtde control 

system. With the introduction of the SG, throtde control is applied on a per ESME 
basis, A maximum message rate is established for each ESME and enforced by the SG. 
Thus the present invention addresses the unfairness of the previous throtting methods 
by transmitting throtde error messages on a per ESME basis, not on an aggregate 

15 message flow basis. The message flow from each ESME can be controlled with this 
approach. This in effect allocates capacity to each ESME. 

Prior to summarizing throtde control according to the present invention, we turn 
to an introduction to the SG and supporting technology surrounding the invention. 

The SG of the present disclosure provides a single logical interface for all SMPP 

20 messages going to and from the messaging complex and eliminates the need for ESMEs 
to have any implementation knowledge of the messaging complex or wireless network. 
The SG provides routing from an ESME to the destination MC based on service being 
delivered and provides MC reconfiguration capability that does not require 
reconfiguration of ESMEs. The SG also provides efficient scaling in the SG as traffic 

25 increases and achieves minimal delay in message delivery. The SG routing system 
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minimizes or eliminates the modification of any parameters in SMPP messages and is 
configurable to support all SMPP message types. 

In order to achieve the advantages of the present invention, the following system 
is used. The disclosed system enables an ESME to submit messages for delivery to a 
5 wireless device. One aspect of the disclosure relates to mobile terminated (MT) 

messages. The system involves implementing an external interface to the messaging 
complex and enables all ESMEs to communicate with the messaging complex using a 
consistent standard interface. 

According to this disclosure, a system for allowing an external short message 

10 entity to submit a message to be delivered to a message-receiving de\dce in a wireless 
network comprises an SG communicating with a pluralitj^ of messaging centers and 
communicating with a plurality of ESZvlEs. The ESME connects or "binds" to the SG 
and requests delivery of a message to a wireless device. The SG routes the request to an 
appropriate messaging center. The SG is configured such that any external short 

15 messaging entity only needs to have knowledge of a single protocol for requesting 
delivery of messages from the SG. 

The ESME also connects to the SG by submitting a bind request signal including 
a system identification, password and system type. The SG responds to the bind request 
with a bind response signal including a system identifier and an error message if a bind is 

20 not successfiil. If a bind is not successful, the bind response signal includes an error 
signal indicating why the bind was not successful. 

An important feature of the disclosure is that the SG determines the routing 
method based on a service type. The SG communicates with a plurality of messaging 
centers and determines the routing method to a destination message center according to 

25 the service type. The routing method may one chosen from a group comprising: 



6 



message center specific, load balancing, MDN range, equal allocation, and ESN. Other 
routing methods maj^ also be added. 

The method disclosed herein enables an ESME to submit messages to be 
delivered to a wireless device. The method comprises requesting deUvery of a service to 

5 a wireless device from an SG, routing the request to a message center according to a 
service type and a routing method, and delivering the request to a wireless network. 

Another aspect of this disclosure comprises a system for transmitting short 
messages from a mobile station to an ESME. These are mobile originated (MO) 
messages. This aspect of the disclosure comprises a system for allowing a message 

10 source to submit a message to be delivered to a message-receiving device. The system 
comprises a short messaging point-to-point gateway communicating with a plurality of 
messaging centers. The messaging centers communicate with a wireless network 
associated with the message-originating soxirce. The message source transmits the 
message to one the plurality of messaging centers, and the one of the plurality of 

15 messaging centers requests from the SG delivery of a message to the message-receiving 
device. The SG routes the request to the messaging receiving device. The SG 
determines a routing method based on a service type. TTie short messaging point-to- 
point gateway is configured to inquire whether anti-spamming is enabled according to a 
seirvice type. 

20 According to the disclosure related to MO messages, the message source 

connects to the one of the plurality^ of messaging centers by submitting a short message 
containing teleservice ID ^D), bearer data, source address and destination address. 
One of the plurality of messaging centers transmits a delivery short message signal to the 
SG. The SG determines a routing method based on a service type. The service types 

25 available from which to choose include, but are not limited to: ESME specific, load 
balancing, equal allocation, destination IP address, and destination address. 
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Having introduces some of the elements and functionalit)^ surrounding the 
throtde control concept of the present invention, we now turn more specifically to 
throttle control The SG according to the present invention also performs throtde 
control Throtde control relates to controlling tiae number of messages sent by ESMEs 
5 either individually or as group. Throtde conuol according to a metiiod of die present 
invention comprises controlling the delivery of a message sent from each individual 
ESME to a message-receiving device durough die SG. Radier than performing dirotde 
control in the aggregate as previously done, throtde control is performed on an ESME- 
by-ESME basis. The method comprises transmitting a data unit associated widi die 
10 message from the message source to die gateway, determining whedier the message 
source has exceeded a threshold value associated widi sending messages, and 
transmitting a response signal from die gateway to die message source indicating an error 
if the message source has exceeded the threshold value. 

In this manner, throtde control can be performed fairly and equitably in the 
15 system and only prevent ESME's from continuing to send messages diat have exceeded 
the predetermined message delivery limit. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The various embodiments of die invention may be understood widi reference to 
20 the attached drawings, of which: 

FIG. 1 shows a diagram illustrating the prior art architecture for delivering short 
messages through a messaging complex; 

FIG. 2 illustrates the architecture of die system according to the first 
embodiment of the present invention; 
25 FIG. 3 shows the process of an ESME binding to the SG; 

FIG. 4 shows the process of die SG binding to MCs; 
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FIG. 5 illustrates an example of a mobile-terminated message flow; 
FIG. 6 shows exemplar)^ routing of a message based on die service type; 
FIG. 7 illustrates anodier example of a mobile-terminated message delivery flow; 
FIG. 8 shows flow control between an ESME and the SG; 
5 FIG. 9 shows a message delivery with anti-spam check process for mobile- 

originated messages; 

FIG. 10 shows a flow diagram for anti-spam logic for both mobile-originated and 
mobile-terminated messages; 

FIG. 11 shows a mobile- terminated message processing logic; 
10 FIG. 12 shows a flow control message sequence for a scenario where the MC is 

congested and alternate MC's may or may not be available; 

FIG. 13 illustrates a message flow for a mobile-originated message; 

FIG. 14 illustrates exemplary message processing for a mobile-originated 
message; 

15 FIG. 15 shows an exemplary message cancel process; 

FIG. 16 shows a message replacement process; 
FIG. 17 shows a check link status process; 
FIG. 18 shows an alert notification process; 

FIG. 19 illustrates an example of message flow for an activation process; and 
20 FIG. 20 shows an example of the hardware associated with die SMPP gateway. 

DETAILED DESCRIPTION OF THE INVENTION 

The first embodiment of the present invention comprises a system architecture 
for allowing external sources to connect using the short message point-to-point (SMPP) 
25 protocol and request delivery of short messages to wireless subscribers. In the context 
of this disclosure, an SMPP Router (SR) and SMPP Gateway (SG) may be considered die 
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same apparatus. An overview of the system may be understood with reference to FIG, 
2. In this disclosure, since a messaging complex and message center both may be 
shortened to "MC", typically a message center will be shortened herein to "MC" to 
reduce any confusion. Message complexes are referred to using the full name. 

5 As shown in FIG. 2, the system architecture 200 comprises at least one External 

Source of a Message Entity (ESME) 202. Each ESME is connected via a firewall 204 to 
a message complex 216, described in more detail below. Messages may also come from 
the Internet 206 via an ESME email hub 208. Other sources of ESMEs include an 
ESME Over-The-Air Activation Facility - OTAF 210, an ESME paging system such as 

10 the Teknow system 212 using Dual Tone Multi-Frequency (DTMF), Telocator 

Alphanumeric Paging Protocol (TAP), or TNPP protocols, or an ESME Voice Mail 
System (VMS) 214. The Teknow system 212 is a paging system that receives paging 
requests and forwards the request to the message center for deliver}^ using the TNPP 
protocol. The Teknow interface may also use other protocols for delivery, such as SMPP 

15 or DTMF for tone encoding. The Comverse system 214 is a voice mail system that 
forwards voice mail waiting notifications to a gateway. Examples of the kinds of 
messages that may be sent from an ESME include weather reports, stock quotes and the 
like. The overall system according to the present invention may also be called an 
"SMPP Receivership," 

20 The SMPP Receivership 200 rehes on implementing an external interface to the 

messaging complex 216. The messaging complex 216 comprises a plurality of messaging 
centers 224^ - 224^. The subscripts "1" through *'x" with respect to the messaging 
centers indicates that there may be only one messaging center in the message complex 
216 or as many as "x" messaging centers in the message complex 216. The interface 

25 uses SMPP over TCP/IP and allows all ESMEs 202 to communicate with the messaging 
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complex 216 using a consistent standard interface. To accomplish this task, a SMPP 
Gatewa)^ (SG) 222 is introduced into the messaging complex 216 architecture. The 
ESMEs 202 know only about the SG 222 and have no knowledge of the underlying 
implementation of the messaging complex 216 or wireless network. Requiring ESMEs 
5 202 to know only about the SG 222 eliminates the need for the message complex 216 to 
maintain knowledge of die underlying implementation or characteristics of the ESMEs 
202, 

The SG 222 receives a message delivery request and routes the message, based on 
service t3^e and routing methods, to the appropriate message center MC 224^224^ for 
10 delivery to a wireless subscriber 236 in the wireless network. The wireless network 
includes a home location register 226, mobile switching center 232, base stations 234, 
and other standard wireless nodes 228 and 230. These nodes 228, 230 may be, for 
example, a mobile switching center, home location register, a mobile station and the like. 
The SMPP Receiver 200 does not communicate directly with these nodes. 

15 One kind of message that may be transmitted through the SMPP Receiver 200 is 

a mobile terminated (MT) message. An MT message originates at an ESME 202 and is 
meant to be delivered to a wireless service subscriber or a wireless device 236. To 
achieve deliverance of a MT message, an ESME 202 connects to the SG 222 and 
requests deliver)^ of a specific senace to a specific wireless device or mobile station 236. 

20 The SG 222 routes the request to the appropriate MC 2241-224^ for subsequent delivery 
in the wireless network. The SG 222 maintains service to MC 224j-224j^ relationships 
and routing rules. Responses from the MC 224^-224^ are sent to the SG 222 and 
subsequendy to the ESME 202. 

Another type of message that may be transmitted on the system 200 includes a 
25 mobile originated (MO) message or service. This type of message originates with a 
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mobile device 236 to be delivered to an ESME 202. For MO services, the SG 222 
routes the message received from the MC 224^-224^, to an ESME 202. The SG 222 
maintains service to ESME 202 relationships and routing rules. Responses from the 
ESME 202 are sent to the SG 222 and subsequently to the MC 224^ -224,. 

5 In addition to routing messages, spam control is desirable in the SMPP Receivor 

200. The network element D2 220 is an enhanced version of a Detection of Undesirable 
E-mail (DUE) processor 218 that the SG 222 queries for spam control. The D2 220 
may be a separate server or a modtJe running on the DUE 218 or on the SG 222. The 
D2 220 is an enhanced spam control server or processor separate from the xindesirable 

10 message detection server (DUE) 218. If the D2 220 is implemented as a separate server, 
then the functionalit}^ described herein is implemented according to hardware elements 
common to servers, such as a processor, memory, interface controls, etc. These 
elements are known to those of skiU in the art and do not need to be further discussed 
herein. 

15 According to the present invention, the standard DUE capability, for example 

from a DUE server 21 8, is enhanced to support queries from the SG 222. For MT 
messages, spam is defined as the number of MT delivery requests for a specific 
subscriber 236 exceeding a predefined nximber within a specific time interval. For 
example, spam for a particular service type may be defined as 20 delivery requests within 

20 three minutes. For MO messages, spam is defined as the number of MO delivery 

requests from a specific subcriber 236 exceeding a predefined number within a specific 
interval. The following Hst provides some of the major functions of the D2 220.* 

1. The D2 220 receives a query from the SG 222 containing the service type, 
source address and destination address; 

25 2. For MT service, the D2 220 updates its message delivery request coionters for 

the mobile destination number (MDN) contained in the destination address 
parameter. If the number of deliver}^ requests have been exceeded for the 



12 



time interval, then D2 220 returns a status of 'den/. Otherwise, the D2 220 
returns a status of 'allow'; 

3. For MO service, the D2 220 updates its message delivery request counters for 
the MDN contained in the source address parameter. If the number of 

5 deliver}^ requests have been exceeded for the time interval, then the D2 220 

returns a status of 'deny'. Odierwise, die D2 220 returns a status of 'allow'; 
and 

4. The D2 220 maintains a Hst of denied MDNs. If die MDN is on die denied 
list, the D2 220 returns a status of 'deny'. 

10 

According to the preferred mode of die first embodiment of die present invention, 
the following assumptions are made: Nximerous ESMEs 202 will attach to the 
Messaging Complex 216; die ESMEs 202 may be wireless or non-wireless; die 
Messaging Complex 216 will consist of a number of physical MC platforms; die interface 
15 between ESMEs 202, MCs 224,-224,, and SG 222 will be SMPP over TCP/IP; for 

capacity and redundancy purposes, a teleservice may be delivered by more than one MC 
224,-224,; one MC 224,-224, may deliver more dian one teleservdce; physical MC 224j- 
224^ platforms may be supplied by more than one vendor; Teleservice applications may 
be supplied by more than one vendor; teleservices will be delivered in a number 
20 portability environment; services, except for activations, will be mobile directory number 
(MDN) based; ESMEs 202 will communicate with the SG 222 using dedicated network 
connections; traffic between die ESMEs 202 and SG 222 may or may not travel over die 
Internet depending on the security desired; and two over-the-air-activation processor 
(OTAP) nodes will be required for activations. 

25 The SG 222 supports protocol data units (PDUs) defined by die SMPP v 3.4 

specification and is backwards compatible to older versions. The SG 222 also supports 
vendor-specific error codes returned in a command_status parameter. These error codes 
include, for example: "Service Type Not Available" (0x00000410); "ESME Not 
Autiiorized for Service Type" (0x00000411); "Service Denied" (0x00000412); "InvaUd 

30 Service Typt'' (0x0000041 3); "ESME Prohibited" (0x00000414); "Congestion" 
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(0x00000400). These error code values are implemented using the block of error code 
values reserved for vendor-specific errors. 

The SG 222 requires the introduction of the new SMPP error codes described in 
the following Table 1: 



Command Status ^ ^ . 
v^lDescription ^ 


^ '"^^'^^rn. :'''^^CondiSous/Wfe 


a;RetBmied . 


2 


Service type not available 


The SG determines that no MCs are available 
to deliver the requested service. This could 
occur when all MC that deliver a specific 
service type are unavailable. 

For MT messages this error is returned by SG 
to ESME in: 

1 . Submit_SM_Resp 

2. Submit_Multi_Resp 

3. Data_SM_Resp 

For MO messages this error is returned by the 
SG to MC in: 

1. Deliver_SM_Resp 

2, Data_SM_Resp 


ESME not authorized for 
service type 


The SG determines that the ESME is not 
authorized to request delivery of the 
service_type specified in: 

1. Submit_SM 

2. Submit„Multi 

3. Data^SM 

For MT messages this error is returned by SG 
to ESME in: 

1 . Submit_SM_Resp 

2. Submit_Mdti_Resp 

3. Data_SM_Resp 


Service denied 


The SG determines that the message cannot 
be delivered because it failed and-spam check. 

For MT messages this error is returned by SG 
to ESME in: 

1. Submit_SM_Resp 

2. Submit_Multi_Resp 

3. Data„SM_Resp 

For MO messages this error is returned by the 
SG to MC in: 

1. Deliver_SM_Resp 

2. Data_SM_Resp 
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Command Status 
. ^ Description 


. Conditions When Returned - 


ESME Prohibited 


The ESME has been placed in prohibited state 
by administrative action at the SG. ESME 
Prohibited is returned if an ESME attempts to 
bind to the SG if while it has a state of 
prohibited at the SG. 


Congestion 


The MC returns Congestion when its inbound 
message queue exceeds a specific threshold. 
The congestion command„status indicates that 
the ESME should invoke flow control 



Now we turn to a discussion of the binding process between ESMEs 202 and die 
SG 222. In order for an ESME 202 to request and deliver a message according to tht 
present invention, the ESME 202 must "bind" to die SG 222. This process is illustrated 
5 in FIG. 3. The "bind" operation is comparable to logging into a computer system. The 
external system requests a session widi die gateway by presenting an ID and a password. 
If the ID and password are successfully autiienticated, a session is established between 
die gateway and the ESME 202. An ESME 202 binds to die SG 222 as a transmitter for 
mobile terminated (MT) services. A bind request (Bind_Transmitter) includes die 
10 systemjd, a unique identifier for die ESME 202, password, and system_type. 

System_t}^e identifies the type of service that the ESME 202 will deliver. The SG 222 
verifies that the ESME 202 is audiorized using systemjd, password, and system__type. 
The MCs 224i-224, repond widi a Bind_Transmitter_Resp signal including systemjd 
and MC signals. The systemjd identifies die SG 222. If a bind is not successftil, die SG 
15 222 returns the appropriate command_status including Bind Failed, InvaUd Password, 
and Invalid System ID, 

An ESME 202 binds to the SG 222 as a receiver for mobile originating (MO) 
services using the Bind„Receiver PDU. All odier steps are die same as described in the 
Bind_Transmitter signal above. In general, the response from a bind operation indicates 
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whether the bind attempt was successful or the response is an error code describing the 
error that prevented the connection. 

An ESME 202 binds to the SG 222 and aU defined MCs 224i-224, configured 
for MT and MO services as a transceiver/receiver for interactive services using the 
5 Bind_Transceiver PDU. All otiier steps are die same as described in the 

Bind_Transmitter signal At initialization, the SG 222 binds to all of die MCs 224i-224^ 
that it is configured to know about. 

The SG 222 enables the introduction of a different binding concept from 
previous concepts. For MT messages, an ESME 202 binds to the SG 222. The SG 222 
10 binds and maintains binds to many MCs 224j-224^. The mapping of many binds from 
the SG 222 to MC 224i-224^ for MT services and the mapping of many binds from the 
SG 222 to many ESMEs 202 for MO services is a critical functionality for die SG 222. 

For MT services, the SG 222 mantains binds to many MCs 224j-224^ while 
maintaining a single bind to the ESME 202. The ESME 202 does not need to know how 
15 or to which MC 224^-224, to bind. The same concept applies in reverse to MO 

Messages. The SG 222 maintains binds to many ESMEs 202 while maintaining a single 
bind to the MC 224i-224,. The MC 224^-224^ does not need to know how or to which 
ESME 202 to bind. The many binds from die SG 222 to the MCs 224i-224, are 
mapped for MT services and die many binds from die SG 222 to many ESMEs 202 are 
20 mapped for MO ser\dces. The communication between the ESME - SG - and MC is 
accomplished using TCP/IP for transport. The TCP/IP protocol transports die SMPP 
protocol messages. 

The process of die SG 222 binding to the MCs 224i-224^ is illustrated in FIG. 4. 
As shown in FIG. 4, the SG 222 maintains die availability status of each of die MCs 
25 224i-224^ and attempts to rebind in case a bind is lost or fails. As discussed above, there 
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are different binding methods for respective services available: MT service, MO service 
and MT and MO service. 

The SG 222 popxilates the Bind_Transniitter, Bind_Receiver, and 
Bind„Transceiver PDUs according to the bind parameters configured for die MC 224^- 

5 224^. The SG 222 updates its internal routing tables to indicate the status of each MC 
224^-224^. The SG 222 also maintains an association between services and available MCs 
224r224,. In this scenario, the SG 222 maintains a static reference between services and 
each MC 224^-224^. In the preferred mode of the first embodiment of the invention, the 
SG 222 queries the MCs 224^-224, to determine the services each MC 224^224, deUvers 

10 and their status. The SG 222 then preferably binds to the MC 224^-224,. In another 
aspect of die invention, the SG 222 may bind to a service type, ratiier tiian to an MC 
224^224,. 

The binding process includes protocols for handling failed binding scenarios. 
For example, if a bind attempt between the SG 222 and an MC 224,-224, fails, die SG 

15 222 may issue an alarm. The bind fail alarm, if provided, contains, at a minimum, MC 
system Jd, time, and bind failure reason. Additional information may be provided. 

If an estabhshed bind between the SG 222 and an MC 224i-224, fails, die SG 222 
issues an alarm. The bind lost alarm shall contain, at a minimum, MC system Jd, time, 
and bind loss reason if known. Additional information may also be provided, 

20 If a bind attempt between die SG 222 and MC 224,-224, fails, die SG 222 

periodically attempts to establish die bind. If a bind between die SG 222 and a MC 
224i-224, is lost, the SG 222 periodically attempts to reestablish die bind. The SG 222 
maintains a configurable bind retry interval. The bind retry interval appUes to failed and 
lost binds. In the preferred embodiment, die bind retry interval has a resolution of 1 

25 minute and a default value of 5 minutes. However, odier values may be used as retry 
intervals or default values. 
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All bind attempts to MCs 224^-224^, successful or unsuccessful, are logged in the 
event log. The minimum information provided includes time, MC system„id, system 
type, and bind status. If bind status returns as "unsuccessful," the failure reason is 
provided, along with other information if desired. Bind parameters for each MC 224j- 
5 224^ ate configured at the SG 222. A further discussion of the details of bind parameter 
provisioning is provided below. 

It is necessarj^ for the SG 222 to support ESMEs 202 and MCs 224i-224^ 
operating at different SMPP interface version levels. For mobile terminated (MT) 
service, the level of service available in the wireless network is determined by the 

10 interface version available at the MC 224^-224^. An ESME 202 should not be able to 

request ser\dces using an interface version that is not yet supported by the MC 224|-224^. 
If an ESME 202 binds to the SG 222 and requests message delivery at the SMPP 
interface version that is greater than the version supported at the destination MC 224j- 
224^, the message is rejected at the SG 222. Basic backward compatibility rules apply, 

15 The SG 222 routes messages to die selected MC 224i-224, only when the SMPP 
interface version of the selected MC 224^-224^ is equal to or greater than the SMPP 
interface version of the originating ESME 202. The SG 222 rejects messages routed to 
the selected MC 224^-224, when die SMPP interface version of the selected MC 224i- 
224^ is less dian die SMPP interface version of die originating ESME 202. The SG 222 

20 then returns a System Error (0x00000008) error code to the originating ESME 202. 

For mobile originated message service, if an MC 2241-224^ requests message 
delivery at an SMPP interface version that is greater than the version supported at the 
destination ESME 202, the message is rejected at the SG 222. Basic backward 
compatibility rules apply. The SG 222 routes messages to the selected ESME 202 only 
25 when the SMPP interface version of the selected ESME 202 is equal to or greater than 
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the SMPP interface version of the originating MC 224^-224,. The SG 222 rejects 
messages routed to the selected ESME 202 when the SMPP interface version of the 
selected ESME 202 is less than the SMPP interface version of the originating MC 224^- 
224,. The SG 222 in this case returns a System Error (0x00000008) error code to die 
5 originating MC 224,-224,. 

The message flow for a mobile terminated (MT) message is illustrated in FIG. 5. 
In the MT mode, the ESME 202 sends a Submit.SM signal to SG 222. The service„type 
parameter identifies die service to be deUvered. The SG 222 invokes a routing mediod 
based on service_type and routing method dependent parameters to select destination 
10 MC 224j-224,. The MT routing mediods apply for ESME 202 to MC 224,-224, 

communication and include such methods as MC specific, load balancing, MDN range, 
equal allocation and ESN. These will be discussed in more detail below. Using die 
appropriate routing method, a primary destination MC 224,-224, is first selected. If the 
primary destination MC 224,-224, is not available, a secondary MC 224,-224, is selected, 

15 FIG. 6 illustrates the routing based on service_type. Each service type 452 has 

an associated routing method 454. The SG 222 determines a primarj^ 456 or secondary 
458 destination using the routing mediod, routing data 460, and parameters in die SMPP 
message. Service types are defined independendy of the teleservice used to deliver die 
service. This approach allows service types to be created diat are not identified by die 

20 underlying teleservice. 

An ESME 202 requests delivery of a message for a specific service type. The SG 
222 routes the message to die MC 224,-224, tiiat deUvers diat service type. The MC 
224,-224, uses a specific teleservice type to deliver die message. Witii tiiis approach new 
service types, from an ESME perspective, can be introduced widiout the introduction of 

25 new teleservices. Additional service types are configurable in die SG 222. Service types 
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do not have be teleservice-specific as long as there is end-to-end continuity of service 
definition. For example, different priority CMT messages could be assigned different 
service types in the SG 222 and routed to MCs 224,-224, dedicated to high or low 
priorit}^ messages. 

5 For example, the following service types codd be defined in Table 2: 



^ ESME Service Type, J 


^^^^^ 1;,'Bescnption ^ 


SMS 


MTSMS 


SMS - high priority 


MT SMS given higher delivery priority 


SMS - MO 


MO SMS to e-mail address destination 


Information services 


Push information services. Potentially many 
variations of this service type. 


Telematics 


MT and MO telematics services. Potentially 
many variations of this service type. 


WAP 


Interactive services using WAP 


OAA 


Activations 


OAP 


Reprogramming 



The routing methods described herein require that die messagejd parameter 
uniquely identify the message and tiie MC 224,-224, diat delivered the message. The 
messagejd parameter is intended to uniquely identify each message sent between die 

10 ESME 202 and an MC 224,-224,. When a number of MCs 224,-224, are used to deliver 
messages, it cannot be guaranteed that the messagejd returned by a MC 224,-224, will 
be unique across all MCs 224,-224,. To eliminate diis ambiguity, each message passing 
through the gateway requires a unique messagejd. The messagejd must uniquely 
identify the message and die MC 224,-224, tiiat delivered it. A unique messagejd 

15 parameter that identifies bodi a message and message center is required to support 
Query_SM, CanceLSM, and Replace.SM operations. 

To support these operations it is necessary for the SG 222 to return a unique 
messagejd to the ESME 202 with each message submitted. The ESME 202 dien can 
use the messagejd in these operations to uniquely identify die subject message. Several 
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options are possible for providing a unique messagejd. In the preferred embodiment of 
the invention, option 1 below is chosen. These are: 



1. Configure each MC 224i-224^ so that it uses a specific range for the 
messagejd. This will uniquely identify each message and die message 
center that delivered it. The messagejd is recycled widiin its defined 
range on each MC 224i-224^, Up to 65 octets are allowed for 
messagejd. 

2. Have the SG 222 assign a unique messagejd to Submit_SM_Resp, 
Submit_Multi_Resp, Data„SM_Resp, and Deliver„SM_Resp. This could 
be accomplished by prepending a message center key to the messagejd 
returned to from the MC 224i-224,. For example, a new messagejd = 
MC_key + MC messagejd. 

The routing methods introduced above establish the rules used to route messages 
to a destination. Different routing rules are used for MT and MO messages. MT routing 
methods apply to ESME 202 to MC 224,-224^ routing. A MT service type can have one 
of the following routing methods shown in Table 3: 



MC Specific 


Route all messages for this service type to a specific 
MC. 


Load Balancing 


Route messages to a group of MCs based on load 
capabilities of each MC in the group. Each MC in 
the group is allocated messages based on its 
capacity. 


MDN Range 


Route to a specific MC based on the MDN range of 
the destination address. The objective of this 
routiQg method is to provide deterministic routing 
for a group of MCs delivering a service that require 
Replace if Present (RIP). For RIP to be effective 
messages for the same destination must be routed to 
the same MC for delivery. 


Equal Allocation 


Route messages to a group of MCs based on 
sequentially sending messages to each MC in the 
group. Each MC in the group gets an equal number 
of messages. 


ESN 


For OATS use ESN to route to the destination MC. 



The following Table 4 describes the SMPP PDUs and parameters used for each 
MT routing method. 
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^ ' ' Houting ^ ; 
^ ! " Method \ 


; SMPP PDUs 


" SMPP 

Parameters Used ; 
^for .Rou& 


,1 ^.;riPs 

..Supported 


Query 
.^ijppqrted 


MC Specific 


Submit_SM 
Data^SM 
Submit Multi 


-service_type 


Yes 


Yes 


Load 
Balancing 


Submit„SM 

Data_SM 

Submit_Multi 


-service_t}^e 


No 


Yes 


MDN Range 


Submit„SM 
Data_SM 
Submit Multi 


-service_type 
-destination__addr 


Yes 


Yes 


Equal 
Allocation 


Submit_SM 

Data_SM 

Submit„Multi 


-service_type 


No 


Yes 


ESN 


Submit_SM 


-service_type 
-short_message 


Yes 


Yes 



We first discuss the MC Specific routing mediod. The SG 222 routes all 
Submit__SM, Data_SM, or Submit_Multi PDUs with the same service_type to the same 

5 MC 224^224^. The MC Specific routing method allows a primary and alternate 

destination MC to be defined, aldiough definition of an alternate MC 224|-224^ is not 
mandatory. The MC Specific routing method routes the MT message to the primary 
destination MC 224,-224, if die primary MC 224i-224, is available. If die primary 
destination MC 224^-224, is not available, die MC Specific routing mediod routes die 

10 MT message to the alternate destination MC 224i-224^. 

If botii primary and alternate MCs 224i-224^ are unavailable, tiie MC specific 
routing mediod responds to the ESME 202 with a command^status of Service Type Not 
Available in die Submit_SM„Resp, Data^SM^esp, or Sumibt_Multi-Resp PDUs if die 
SG 222 cannot route a message to an MC 224i-224, because all MCs 224r224, defined to 

15 deliver the service^type are unavailable. 

The Load Balancing routing method routes messages to a group of MCs 224i- 
224, based on load capabilities of each MC 224i-224, in tiie group. Each MC 224^224^ 
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in the group is allocated messages based on its capacity. For example, Table 5 illustrates 
the proportioning of messages: 



„"MCin ■ 
, ,'sGroup . 


■ :^ Prdporrion of Messes _ ' , i 1 
.•■ . . ', - ' -Allocated. : "■1 


MC-1 


25% 


MC-2 


50% 


MC-3 


25% 


Total 


100% 



The SG 222 provides a Load Balancing routing mediod for MT messages. The 
5 Load Balancing routing method routes Submit_SM, Data_SM, or Submit_Mulri PDUs 
with the same service_type to one of a group of MCs 224^-224^ based on die message 
allocation estabUshed for each MC 224,-224,. The Load Balancing routing mediod 
allows a group of MCs 224,-224, delivering die same service_type to be defined. The 
group contains two or more MCs 224^-224,. This routing mediod also aUows die 
10 proportion of messages allocated to each MC 224,-224, in die group to be defined. The 
proportion is defined as a percentage of messages allocated to each MC 224^-224^. 

The Load Balancing routing mediod routes messages to each of die MCs 224,- 
224, in the load balancing group based on proportion of messages allocated to each MC 
224,-224,. Using die example above, if 100 messages are routed for a service type in 
15 some time interval, MC-1 will receive 25 messages, MC-2 will receive 50 messages and 
MC-3 will receive 25 messages. If an MC 224,-224, in a Load Balancing routing 
method group becomes unavailable, the messages destined for die unavailable MC 224,- 
224, are routed to the remaining MCs 224,-224,. The messages are allocated to die 
remaining available MCs 224,-224, based on die remaining MCs 224,-224, allocation of 
20 total capacity. The allocation added to each remaining MC 224,-224, equals die aUocation 
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lost / nximber remaining MCs 224j-224^. Using the example above, suppose MC-3 
becomes unavailable. Allocation added to each remaining MC = allocation lost / 
number of remaining MCs. Allocation added to each of the remaining MCs = 25% / 2 
(=12.5%). MC-1 is now aUocated 37.5% of the total (25% + 12.5% from MC-3). MC-2 
5 is allocated 62.5% of the total (50% + 12.5% from MC-3). 

If both primar}^ and alternate MCs are unavailable, the Load Balancing routing 
method responds to the ESME 202 with a command_status of Service Type Not 
Available in the Submit„SM_Resp, Data_SM_Resp, or Submit_Multi-Resp PDUs if the 
SG 222 cannot route a message to an MC 224|-224^ because all MCs 224|-224^ defined to 
10 deliver the sendce_type are unavailable. 

The MDN range routing method routes messages to a specific MC 224i-224j, 
based on the MDN range of the destination address. The objective of this routing 
method is to pro\dde deterministic routing for a group of MCs 224^-224^ delivering a 
service that requires guaranteed message delivery order or Replace If Present (RIP). For 
15 RIP to be effective, messages for the same destination must be routed to the same MC 
224^-224^ for delivery. The MDN range routing method has two possible configurations: 

First, a complete range of MDNs is defined for the MDN routing group (from 
000-000 through 999-999). This is illustrated in Table 6: 



MDN Range ' 

/ ; ' ^ lX)W ; 


' 'MDNRar^^^'^ 

•0'.''' ^"'-'t^^'i 


3;', Primary 
"'t<>'t>.-,'''' ''.', '°K 


•4?- 


001-000 


425-999 


MC-1 


MC-2 


426-000 


605-999 


MC-2 


MC-1 


606-000 


999-999 


MC-3 


MC-2 



20 Second, an incomplete range of MDNs plus a Default MC is defined for the 

MDN routing group. Any destination_address not within the defined MDN ranges is 
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routed to the Default MC, In this example any destination_address that is not in the 
001-000 to 605-999 range is routed to the Default MC. This is shown by way of example 
in Table 7: 



.MDN Range 

' .J' ' i-.. Z ' ■■ '^'^ 


MDN Range : 




Alternate 


001-000 


425-999 


MC-1 


MC-2 


426-000 


605-999 


MC-2 


MC-1 


DefavJt 


Defadt 


MC-3 


MC-4 



5 The MDN Range routing method routes all Submit_SM, Data_SM, or 

Submit_Multi PDUs widi the same service„type to one of a group of MCs 224^-224^ 
based on the value of the MDN in die destination_addr parameter. The MDN Range 
routing method allows a group of MCs 224^-224^ delivering the same service_type to be 
defined. The group contains two or more MCs 2241-224,^. 

10 The MDN range used by the MDN Routing method is defined by a low and a 

high MDN value widi a resolution of NPA-NXX. The MDN Range routing method 
allows MDN ranges to be assigned to each MC 224^-224, in the group. It is possible to 
assign more than one MDN range to each MC 224i-224^. The MDN Range routing 
method does not allow overlapping MDN ranges to be defined for a specific 

15 service_type. 

The MDN Range routing method allows a Default MC to be defined. If die 
MDN received in the destination_address parameter is not within die any of the MDN 
ranges defined for the group, the message is routed to the Default MC. 

The SG 222 issues an alarm when a message is routed to the default MC 224i- 
20 224,. The minimum information provided includes die time, service type, source ESME, 
destination_address of message routed to die default MC, and the default MC. Odier 
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information may also be provided. The SG 222 logs all occurances of messages routed 
to the defaxilt MC 224^224,. The minimum information provided includes time, service 
t)^e, source ESME, destination_address of message routed to the default MC, and the 
default MC. Other information may be provided. 

5 The MDN Range routing method for a specific service_type does not become 

effective unless MDN range definition is complete and provides for routing of any MDN 
(from 000-000 tiirough 999-999) or a Default MC is defined. The MDN Range routing 
method allows definition of an alternate MC 224^-224^ for each MDN range. 

If the primar}^ MC 224^-224^ for die MDN range is not available and an alternate 

10 MC 224^224^ is defined and available, the MDN Range routing method routes messages 
to die alternate MC 224i-224,. If die primary MC 224i-224^ for die MDN range is not 
available and an alternate MC 224,-224^ is not defined or not available, die MDN Range 
routing method responds to die ESME 202 with a command_status of Service Type Not 
Available in the Submit_SM_Resp, Data_SM_Resp, or Submit_Multi-Resp PDUs, if die 

15 SG 222 cannot route a message to an MC 224^-224, because all MCs 224i-224^ defined to 
deliver the service_type are unavailable. 

The equal allocation routing method routes messages to a group of MCs 224^ 
224^ based on sequentially sending messages to each MC 224i-224^ in the group. Each 
MC 224j-224^ in the group is sent an equal number of messages. The SG 222 provides 

20 an Equal Allocation routing method for MT messages. The Equal Allocation routing 
method routes all Submit_SM, Data_SM, or Submit_Multi PDUs with die same 
service_type to one of a group of MCs 224i-224j^ based on sequentially sending messages 
to each MC 224^-224^ in die group. The Equal Allocation routing method allows a 
group of MCs 224^-224^ deUvering the same service_type to be defined. The group shall 

25 contain two or more MCs 224i-224^. 
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The equal allocation routing method sends an equal number of messages to each 
MC 224^-224, in the group. One message is sent to each of the destination MCs 224i- 
224^ before any destination MC 224^-224^ is sent anodier message. If a MC 224^-224, in 
an Equal Allocation routing mediod group becomes unavailable, messages destined for 

5 the unavailable MC 224r224, are routed to die remaining MCs 224i-224^ widiin die 

group. If all MCs 224i-224, in an equal allocation routing group become xinavailable, die 
routing method responds to tht ESME 202 widi a command„status of Service Type Not 
Available in die Submit_SM_Resp, Data_SM_Resp, or Submit_Multi-Resp PDUs if die 
SG 222 cannot route a message to an MC 224i-224, because aU MCs 224^224, defined to 

10 deliver the service_t}^e are unavailable. 

We now turn to an overview of the activation process for a mobile station 236. 
Activation requests are sent to an over-the-air-activation processor (OTAP) MC 224^- 
224, delivering the OATS teleservice. For activation, die destination_address parameter 
in the Submit_SM contains die mobile identification number (MIN) to be assigned to the 

15 MS 236. The short_message parameter contains die ESN along widi otiier activation 
data. Each MS 236 has a unique activation MIN diat follows die standard NPA-NXX- 
XXX format: NPA is always 000; NXX-XXX is derived from die ESN. The MS 236 
registers at the OTAP MC 224^-224, using die activation MIN (not die MIN to be 
assigned to die MS). The OTAP MC 224r224, associates tiie activation MIN widi the 

20 ESN received in Submit_SM and subsequendy sends die activation data to die MS 236. 
The following example describes how the activation MIN is derived from the ESN. 

1. The ESN is 4 octets in length. The first octet is the manufacture code and 
the remaining three octets are the ESN. For example, a decimal ESN = 
12205092081 p7 hex 7A EC Fl hex). 

25 

2. The manufacture code (Dl hex) is dropped leaving 7A EC Fl hex. 

3. This value is converted to decimal: 7A EC Fl hex = 8056049 decimal 
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4. The least significant seven digits are used as the NXX-XXX portion of die 
activation MIN. The least significant seven digits of the ESN are appended 
to the activation NPA, 000, resulting in an activation MIN of 0008056049. 

5 The ESN routing method is used to route activation requests to two or more 

MCs 224,-224, delivering die OATS teleservice. If two OATS MCs 224,-224, are used, 
then routing is based on the odd - even value of the decimal ESN. One MC 224,-224^ 
receives activation requests witii even ESNs, one MC 224,-224, receives activation 
requests with odd ESNs. If more tiian two OATS MCs 224,-224, are used, tiien routing 

10 is based on an ESN range assigned to each MC 224,-224, in the group. The ESN range 
is defined by the last two digits of die decimal ESN. This allows up to 100 MCs 224,- 
224^ in a group. For example, Table 8 illustrates die ESN ranges: 



„=.;MCin' •• . 
• • ,;Group . j 


■■ESN Range, J 
, .--Low ;~.2*-J 


■ ' ESN Range : 

.2lji#;..,fligh.r;;._, ':j 


OATS-1 


00 


33 


OATS - 2 


34 


67 


OATS -3 


68 


99 



The SG 222 pro\ades an ESN routing method. The ESN routing method shall 
15 route Submit_SM PDUs with the same service_type to one of a group of MCs 224^-224^ 
based on the value of the ESN in the short_message parameter. The ESN routing 
method shall allow a group of MCs 224,-224, deHvering the same service_type to be 
defined. The group shall contain two or more MCs 224i-224,. The ESN routing 
method supports two routing options: 

20 1. When an ESN routuig group contains two OATS MCs 224^-224,^outing 

shall be based on the odd or even value of the decimal ESN. 

2. When an ESN routing group contains more than two OATS MCs 224,-224^, 
routing shall be based on the value of the last two digits of the decimal ESN. 

25 
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When the ESN routing group contains two MCs 224^-224,, one MC 224,-224, is 
defined to receive activation requests containing even ESNs in the short„message 
parameter and one MC 224^-224^ is defined to receive activation requests containing - 
odd ESNs in the short__message parameter. The reqxiirements in the following 
5 paragraph apply only to routing to more than two MCs 224i-224^. 

When the ESN routing group contains more than two MCs 224i-224^, the ESN 
routing method reqxiires an ESN range be defined for each destination MC 224i-224^ in 
the group. The ESN range used by the ESN routing metiiod is defined by a low and 
high value for the last two digits of the ESN. The ESN routing method does not allow 
10 overlapping ESN ranges to be defined for a specific service_type. The ESN routing 
method for a specific service_type shall not become effective unless die ESN range 
definition is complete and provides for routing of any ESN (last two digits from 00 
through 99). 

If the destination MC 224^ -224, for die ESN is not available, die ESN routing 
15 method responds to the ESME with a command_status of service type Not Available in 
the Submit_SM_Resp, Data_SM_Resp, or Submit_Multi_Resp PDUs if die SG 222 
cannot route a message to an MC 224i-224, because all MCs 224^-224^ defined to deliver 
the service_type are unavailable. 

The column of Table 4 labeled Query Supported represents support for 
20 Query_SM, Cancel_SM, and Replace_SM operations. The Submit„SM_Resp, 

Data„SM_Resp, and Submit_Multi_Resp signals return a unique message Jd to the 
sending ESME 202 for each message submitted. The messagejd uniquely identifies die 
message and the MC 224^-224^ tiiat sent die message. The ESME 202 populates die 
messagejd parameter in die Quer}^_SM, CanceLSM, and Replace_SM operations widi 
25 the messagejd returned in the original submission. The Query_SM, Cancel_SM, and 
Replace_SM operations are discussed in more detail below. The SG 222 uses the 
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message Jd to route the message to the correct MC 224i-224,. The MC 224,-224, uses 
the messagejd and associated parameters received in the message to perform the 
requested operation. 

To make most efficient use of MC 224i-224, and wireless network resources, RIP 
5 are used by the ESME 202 when possible. To effectively implement RIP, all messages 
for the same service type and destination address (MDN) must be routed to die satne 
MC 224i-224^ for delivery. If a pending message for die service type and destination 
address (MDN) is present, it is replaced witii the new message. This is not a problem 
when only one MC 2243-224, delivers a service. When a group of MCs 224,-224^ 
10 delivers the same senace, the problem is determining which MC 224^ -224^ in the group 
may contain a pending message tiiat should be replaced by the current message. 
Several solutions are possible: 

1, Allow all MCs 224i-224^ delivering a service to access a shared database of 
pending messages. RIP could then be implemented effectively by a group of 

15 MCs 224i-224,. Current MC 224^-224^ architecture does not support diis 

approach. 

2. Establish a routing type at die SG 222 diat routes a delivery request to die 
same MC 224, -224^ given service type and destination address. 

' 20 Routing by MDN range implements option two above. For example, a service 

type requiring RIP is deUvered by multiple MCs 224,-224,. An NPA range is estabUshed, 

in the SG 222, for each MC 224,-224,, The SG 222 routes messages to die MCs 224,- 

224,, based on service type and NPA of the destination address (MDN). Subsequent 

messages for the same service type and MDN are routed to the same MC 224|-224x using 

25 the MDN of the destination address. If RIP is requested and a message is pending, it is 

replaced at the MC 224,-224,. 

With diis routing method die MDN range has no significance to die MC 224,- 

224, or in the wireless network; it is only used as a routing mechanism between die SG 

222 and MC 224,-224,. 
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We now turn to routing methods for mobile originated messaging. The MO 
routing methods apply for MC 224,-224, to ESME 202 routing. A MO service type can 
have one of the following routing methods, illustrated in Table 9: 



ESME Specific 


Route all messages for this service type to a specific 
ESME. 


Load Balancing 


Route messages to a group of ESMEs based on load 
capabihties of each ESME in die group. Each 
ESME in the group is allocated messages based on 
its capacit^^ 


Equal Allocation 


Route messages to a group of ESME based on 
sequentially sending messages to each MC in the 
group. Each ESME in die group gets an equal 
number of messages. 


Destination IP 
Address 


Route messages to destination based on IP address 
contained in destination_address parameter of 
Delivery SM and Data_SM. 


Destination 
Address 


Route message to a destination ESME based on the 
value of the destination_addr parameter received in 
the Deliver SM and Data„SM PDUs 



The following Table 10 describes die SMPP PDUs and parameters used for each 
MO routing method. 



^ /:ljoutin^ 


;^^SMPP.E1^s;S^ 


^ME^ Param^tes liJsed for _ J 

>Jtt'^P^tirig^-': 


ESME Specific 


Deliver_SM 
Data_SM 


-service^tjrpe 


Load Balancing 


Deliver_SM 
Data_SM 


-service_type 


Equal Allocation 


Dehver_SM 
Data_SM 


-service__type 
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Destination IP 
Address 


Deliver_SM 
Data_SM 


-desrination_address 
-service_type 


Destination Address 


Deliver_SM 
Data_SM 


-destination_address 
-service_type 



For destination address routing, die destination_address parameter contains the 
IP address of the destination ESME 202. The SG 222 routes to the ESME 202 using the 
IP address in the destination_address parameter. Routing is subject to destination ESME 
5 202 being bound and anti-spam check based on service_type parameter. 

For the ESME 202 specific routing method, die SG 222 routes all Deliver_SM 
and Data.SM PDUs with the same service„type to die same ESME 202. The ESME 
Specific routing method allows a primary and alternate destination ESME 202 to be 
defined. Definition of an alternate ESME 202 is not mandatory. The ESME 202 

10 Specific routing method routes the MO message to the primar}^ destination ESME 202 if 
the primar}^ ESME 202 is available. The ESME 202 Specific routing method routes die 
MO message to the alternate destination ESME 202 if the primary ESME 202 is not 
available. If both primary and alternate ESMEs 202 are unavailable, the ESME 202 
specific routing method responds to die MC 224i-224, widi a command_status of service 

15 type not available in the Deliver__SM_Resp or Data_SM_Resp PDUs if the SG 222 
cannot route a message to an ESME because all die ESMEs defined to receive die 
service_type are unavailable. 

The Ix)ad Balancing routing method routes messages to a group of ESMEs 202 
based on load capabilities of each ESME 202 in the group. Each ESME 202 in die 
20 group is allocated messages based on its capacit}\ Table 11 illustrates die message 
allocation: 



- ESMEiin' \s 


l?i:opottiori of Messages , 


"^^^■^''Group"^ - 


'K.. H;iylocated..; ' " : 
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ESME-1 


25% 


ESME-2 


50% 


ESME-3 


25% 


Total 


100% 



The SG 222 provides a load balancing routing method for MO messages. The 
load balancing routing method routes aU DeHver_SM or Data_SM PDUs widi die same 
service_t}T)e to one of a group of ESMEs 202 based on die load allocation established 
5 for each ESMEs 202. The load balancing routing mediod allows a group of ESMEs 202 
delivering the same service„type to be defined. The defined group contains two or more 
ESMEs 202, The load balancing routing metiiod allows die proportion of messages 
aUocated to each ESME 202 in the group to be defined. The proportion is defined as a 
percentage of messages allocated to each ESME 202. The load balancing routing 
10 method farther routes messages to each of die ESMEs 202 in die load balancing group 
based on proportion of messages aUocated to each ESME 202. 

Using the example above, if 100 messages are routed for a service type in some 
time interval, the ESME-1 will receive 25 messages, die ESME -2 will receive 50 
messages and the ESME -3 will receive 25 messages. The load balancing routing mediod 
15 routes messages to each of the ESMEs 202 in die group based on die proportion of 
messages allocated to it. If an ESME 202 in a load balancing routing mediod group 
becomes unavailable, die messages destined for the unavailable ESME 202 are routed to 
die remaining ESMEs 202. The messages are allocated to die remaining available 
ESMEs 202 based on the remaining ESMEs 202 allocation of total capacity. The 
20 allocation added to each remaining ESME 202 equals die allocation lost / number of 
remaining ESMEs 202, 

Using the example above, if die ESME-3 becomes unavailable, then die 
allocation added to each remaining ESME - allocation lost / number of remaining 
ESMEs. The result of the allocation added to each of die remaining ESMEs = 25% / 2 
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(=12.5%). ESME-1 is now aUocated 37,5% of the total (25% + 12.5% from ESME-3) 
and ESME-2 is aUocated 62.5% of the total (50% + 12.5% from ESME-3). If all 
ESMEs 202 in a load balancing routing group become xinavailable, the routing method 
responds to the MC 224^-224^ with a conimand_status of service type not available in die 
5 Deliver_SM_Resp or Data_SM„Resp PDUs if die SG 222 cannot route a message to an 
ESME 202 because all die ESMEs 202 defined to receive die service^type are 
unavailable. 

The SG 222 also provides for routing according to the equal allocation mediod. 
According to the equal allocation metfiod, all Deliver^SM and Data_SM PDUs are 

10 routed with the same service_type to one of a group of ESMEs 202 based on 

sequentially sending messages to each ESME 202 in the group. The equal allocation 
routing method allows a group of ESMEs 202 delivering the same service_type to be 
defined. The group contains two or more ESMEs 202. The equal allocation routing 
method sends an equal number of messages to each ESME 202 in the group. One 

15 message shall be sent to each of the destination ESMEs 202 before any destination 
ESME 202 is sent another message. If all ESMEs 202 in an equal allocation routing 
group become unavailable, the routing method responds to the MC 224i-224^ with a 
command_status of service type not available in the Deliver_SM„Resp or 
Data_SM_Resp PDUs if the SG 222 cannot route a message to an ESME 202 because all 

20 the ESMEs 202 defined to receive the service_type are unavailable. 

Another routing method is the destination IP address routing method. 
According to the destination IP address routing method, the SG 222 routes all 
Deliver_SM and Data_SM PDUs with the same service„type to die address contained in 
the destination_address parameter. 

25 The destination address routing method differs from the destination IP address 

routing method as follows. The SG 222 provides a destination address routing method 



for MO messages. The destination address routing method routes all Deliver_SM and 
Data_SM PDUs widi the same service_t}^e to a destination ESME 202 based on die 
value of the first four digits of die destination_addr parameter. The first four digits of 
die destination_addr parameter identify the ESME 202 to which die message should be 
routed. The destination address routing mediod aUows destination address values to be 
assigned to an ESME 202. It is possible to assign more dian one destination address 
value to an ESME 202. The destination address assigned to an ESME 202 is four digits 
in lengdi. VaUd destination address values are 0000 to 9999. ITie destination address 
routing mediod routes die DeUver_SM and Data_SM PDUs to the destination ESME 
202 based on die value of die first four digits of die destination_addr parameter received 
in the Deliver_SM and Data^SM PDUs. 

The SG 222 maintains an association between die four-digit destination address 
value and an ESME 202. An example is shown in die following Table 12. 



-'Destination address value ' 




0000 


e-mail hub 


1234 


ESME A 


1236 


ESMEB 


1237 


ESMEB 


2570 


ESMEC 



Given the destination address to ESME 202 associations shown in die previous 
table, the following Table 13 shows example routings. 



,v -desdnation^ddr l 
" Parameter Value : 




OOOOxxxx 


e-mail hub 


1234xxxx 


ESME A 


1234x 


ESME A 


2570 


ESMEC 


7230 


Return error code 


1236XXXX 


ESMEB 


1237 ESMEB 
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If the value received in the first four digits of the destination_addr parameter 
does not correspond to any defined destination address values, the SG 222 returns an 
InvaUd Dest Addr (OxOOOOOOOB) error code to the MC 224,-224,. The SG 222 issues an 
alarm when an Invahd Dest Addr (OxOOOOOOOB) error code is sent to a MC 224,-224,. 
5 The minimum information provided includes time, service type, source MC 224,-224,, 
and destination_addr of message. Odier information may be provided. 

The SG 222 logs all occurrences of an Invalid Dest Addr (OxOOOOOOOB) error 
code being sent to an MC 224i-224,. The minimum information provided includes time, 
service type, source MC, and destinarion_addr of message. Odier information may be 
10 provided. 

If the destination ESME 202 for the destination address is not available, the SG 
222 responds to tiie MC 224,-224, with a conomand.status of Service Type Not 
Available in the DeUver„SM_Resp or Data_SM_Resp PDUs if die SG 222 cannot route 
a message to an ESME 202 because all ESMEs 202 defined to receive die service_type 
15 are unavailable. 

Having discussed both die MT and MO routing metiiods, we now turn to a 
discussion of die message Jd parameter. The messagejd parameter is returned to an 
ESME 202 by the MC 224,-224, when a message is submitted for delivery. The 
messagejd value is used subsequendy by die ESME in Query, Cancel, and Replace 
20 (QCR) operations. The SG 222 supports diree messagejd mapping modes. These are 
sxxmmarized in the following Table 14: 



; r -messa^ id Mapping Mode 




Mode 1 - unique messagejd 
appUed at MC 


MC provides unique messagejd 
values within a specific range, SG 
routes QCR PDUs based on 
messagejd range to MC mapping 
maintained at SG. 


Mode 2 - unique messagejd 
applied at SG 


SG prepends a message center ID 
value to messagejd parameter 
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received from MC. SG routes 
QCR PDUs based on message 
center ID value mapping 
maintained at SG. 


Mode 3 — Query, Cancel, Replace 
not supported at SG 


The SG rejects all QCR PDUs. 



When mode - 1 message__id mapping is selected, the SG 222 uses the 
provisioned MC 224i-224^ message_id range to route CanceLSM, Replace_SM, and 
Query_SM PDUs to destination MCs 224i-224^. 

5 If the MC 224i-224j^ cannot provide unique message„id values in response PDUs, 

the SG 222 will provide this function. This is accomplished at the SG 222 by prepending 
a unique message center ID (MCID) value to the message„id value returned by the MC 
224i-224^ in die Submit_SM_Resp, Submit_Multi_Resp, Data_SM_Resp, and 
Deliver_SM„Resp PDUs. The SG 222 also is required to remove the prepended MCID 

10 values in Query_SM, CanceLSM, and Replace_SM PDUs. 

The modified message_id will have the form of MCID + message_id. Note that 
message ID mapping at SG 222 is only required to support CanceLSM, Repiace_SM and 
Query_SM operations. The discussion below on MC Provisioning provides further 
details regarding the MCID, message ID mapping at SG 222, and MC message_id range 
15 parameters. 

The SG 222 provides a message ID mapping at SG master on / off setting for 
each MC 224i-224,. If message ID mapping at SG 222 is set to on for a MC 2243-224^, 
dien the SG 222 requires a unique MCID value be defined for tiiat MC 224i-224^. The 
MCID values are unique to a MC 224^-224^. If the message ID mapping at the SG 222 is 
20 set to off, then the SG 222 does not provide unique message„id mapping for the MC 
2245-224^. The SG 222 assumes that the MC 224i-224jj provides unique message_id 
values as defmed by the MC message_id range parameter. The SG 222 provides a 
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configurable MCID value for each MC 224,-224, defined at die SG 222. The MCID 
value is configurable between 001 and 999. 

When die SG 222 receives a Submit_SM„Resp, Subimt_Multi_Resp, 
Data_SM_Resp, or Dehver„SM_Resp PDU and message ID mapping at SG 222 is set to 

5 on, dien die SG 222 prepends the MCID value to die message Jd value returned firom 
the MC 224i-224^. The SG 222 dien sends die response PDU containing die modified 
message Jd to die destination ESME 202. When die SG 222 receives a Query.SM, 
CanceLSM, or Replace_SM PDU with a message center ID prepended to die 
messagejd, the SG 222 removes die MCID firom die messagejd. The SG 222 then 

10 sends the PDU containing die messagejd (widi MCID removed) to die destination MC 
224,-224,. 

The SG 222 uses the MCID prepended to die messagejd in the Query^SM, 
CanceLSM, or Replace„SM PDUs to route die PDU to the correct MC 224,-224,. The 
PDU is routed to die MC 224,-224, identified by die MCID. If die SG 222 receives a 
15 Query_SM, Cancel_SM, or RepIace_SM PDU widi a messagejd widiout a MCID 
prepended, die SG 222 attempts to route die PDU using die MC messagejd range 
parameter provisioned for die MC 224,-224,. If die routing attempt fails, die SG 222 
returns Service type not available error code to the originating ESME 202. 

When messagejd mapping mode 3 is selected. Query, Cancel, and Replace 
20 PDUs are rejected at die SG 222. The SG 222 rejects diese PDUs widi die appropriate 
error code. When mode - 3 messagejd mapping is selected, die SG 222 rejects (1) all 
CanceLSM PDUs widi the CanceLSM Failed error code, (2) all Query_SM PDUs widi 
die Query_SM Failed error code, and (3) all Replace_SM PDUs widi die Replace_SM 
Failed error code. 

25 The messagejd mapping mode is configurable at the SG 222. Mode one, two, 

or three may be selected. 
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We will next discuss the query, cancel, and replace commands. The SG 
222 supports receiving Quer}^_SM and Quer}^_SM_Resp PDUs. When the SG 
222 receives a Quer}^„SM PDU, it routes the message to the MC 224^-224^ 
identified by die messagejd parameter. When the SG 222 receives a 

5 Quer}^_SM_Resp, it routes the message to the originating ESME 202. If the 
destination MC 224, -224^ is unavailable or the messagejd parameter does not 
map to a known MC 224i-224,, die SG 222 responds to the ESME 202 widi a 
command_status of Service Type Not Available in die Submit„SM_Resp, 
Data_SM_Resp, or Submit_Multi_Resp PDUs if the SG 222 cannot route a 

10 message to a MC 224i-224, because aU MCs 224,-224, defined to deliver die 
service_type are unavailable. 

The SG 222 supports receiving CanceLSM and CanceLSM_Resp PDUs. When 
the SG 222 receives a CanceLSM PDU with a messagejd value diat is not null, it will 
route the message to the MC 224^-224^ identified by die messagejd parameter. When 

15 the SG 222 receives a CanceLSM_Resp, it routes die message to die originating ESME 
202. When the SG 222 receives a CanceLSM PDU widi a messagejd value diat is null, 
it routes the message to the MC based on the service_type parameter. If the service__type 
is defined widi the MC Specific or MDN Range routing methods, die CanceLSM PDU 
is routed according to the rules of the routing method. If the service_type is defined 

20 with any other routing mediod, the SG 222 responds to the ESME 202 widi a 
command^status of Service Type Not Available in the Submit_SM„Resp, 
Data_SM_Resp, or Submit„Multi_Resp PDUs if the SG 222 cannot route a message to a 
MC 224,-224^ because all MCs 224r224, defined to deliver the service.type are 
unavailable. 
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If the destination MC 224^-224^ is unavailable or the message_id parameter does 
not map to a known MC 224^-224,, the SG 222 responds to the ESME 202 with a 
command„status of Service Type Not Available in the Submit_SM_Resp, 
Data_SM_Resp, or Submit_Multi_Resp PDUs if the SG 222 cannot route a message to a 
5 MC 224^224^ because all MCs 224i-224^ defined to deliver the service_type are 
unavailable. 

The SG 222 supports receiving Replace_SM and Replace_SM_Resp PDUs. 
When the SG 222 receives a RepIace_SM PDU, it routes the message to the MC 224i- 
224^ identified by the message_id parameter. When the SG 222 receives a 

10 Replace„SM_Resp, it routes the message to the originating ESME 202. If the destination 
MC 224|-224x is tinavailable or the message_id parameter does not map to a known MC 
224^-224j^, the SG 222 responds to the ESME 202 with a command_status of Service 
T}Tpe Not Available in the Submit_SM_Resp, Data_SM_Resp, or Submit_Multi_Resp 
PDUs if the SG 222 cannot route a message to a MC 224^-224, because all MCs 224j- 

15 224j, defined to deliver the service_type are unavailable. The SG 222 also supports the 
Enquire_Link and Enqmre_Link_Resp PDUs, as well as the Alert_Notification PDU, 
which the SG 222 routes using the esme__addr parameter. 

The SG 222 maintains the operation states of MCs 224^-224^, ESMEs 202, and 
service types. The ESMEs 202 and service type may be disabled administratively. An 
20 ESME 202 may be prohibited from binding to the SG 222. A service type may be 

unavailable at the router because of administrative action or because all of the MCs 224|- 
224^. or ESMEs 202 that provide that service type are unavailable. The SG 222 monitors 
the operating state of all the MCs 224^-224^ that it is configured to route to. A MC 224i- 
224^ has states of available or unavailable. The available state indicates that the MC is 
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operating normally. The unavailable state indicates that the MC 224^224^ is not 
available and no messages will be routed to it. 

The SG 222 maintains the permission state of all ESMEs 202 diat it is 
configured to route to. An ESME 202 contains states of allowed or prohibited. The 

5 allowed state indicates that the ESME 202 is permitted to bind to the SG 222 and send 
and/or receive messages. The prohibited state indicates that die ESME 202 is not 
permitted to bind to the SG 222. If an ESME 202 widi a state of prohibited attempts to 
bind to die SG 222 die SG 222 responds vnxh a command_status of ESME Prohibited. 
If an ESME 202 is bound to the SG 222 and its state is changed to prohibited dirough 

10 administrative action, the SG 222 cancels the ESME's bind. 

A service type may become unavailable for two reasons: First, aO MCs 224i-224^ 
or ESMEs 202 delivering that service type become unavailable; and second, an 
administrator changes die state of service type to unavailable at die SG 222 to prohibit 
access to that service type. The SG 222 maintains the availability state of all service types 
15 to which it is configured to route, A service type has the states of available or 

unavailable. The available state indicates diat the service type is available to ESMEs 202 
(MT case) or MCs 224^-224, (MO case) for routing. The unavailable state indicates die 
ser^dce type is not available to ESMEs 202 (MT case) or MCs 224^224, (MO case). 

If a service type has a state of unavailable the SG 222 responds to the ESME 202 
20 with a command_status of Service Type Not Available in the Submit_SM_Resp, 

Data_SM_Resp, or Submit_Multi_Resp PDUs if die SG 222 cannot route a message to a 
MC 224^224^ because all MCs 224^-224, defined to deliver die service„type are 
unavailable for MT services. The SG 222 responds to die MC 224r224, widi a 
command_status of Service Type Not Available in the Deliver_SM_Resp or 
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Data„SM_Resp PDUs if the SG 222 cannot route a message to an ESME 202 because all 
ESMEs 202 defined to receive the service_type are unavailable, for MO services. 

All changes to Service Type, ESME, and MC provisioning parameters are logged 
in an event log. The minimum information provided includes time, user id of person 
5 making the change, previous parameter value, and new parameter value. Additional 
information may also be provided. 

The SG 222 provides a user interface for service type provisioning and 
configuration reporting. At a minimum, the SG 222 provides the following configurable 
parameters for each service type as shown in Table 15: 

10 



. Parameter 


^'^f ^^Description ^ ' 




Service type 


Identification of service 
type used in the 
service_type parameter 


Implementation specific 


Service termination 
type 


Termination type of 
the service 


MT or MO 


Routing method 


Routing method for 
service type 


For MT services: 

1. MC Specific 

2. Load Balancing 

3. MDN Range 

4. Equal Allocation 

5. ESN 

For MO services: 

1. ESME Specific 

2. Load Balancing 

3. Equal Allocation 

4. Destination IP 
Address 

5» Destination Address 


Anti-Spam Check 
required 


Determines if all 
messages for this 
service type require an 
anti-spam check or not 


Yes or no 


Anti-Spam Check 
unavailable default 
action 


If D2 is unavailable, 
the SG can either allow 
all messages for the 
service type or deny aU 
messages for the 
service type until D2 
becomes available. 


1 . Allow all messages 

2. Deny all messages 
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Parameter " ; 


Description 


, /'Values < : 




This parameter defines 




Service type 
availability 


Service type availability 
allows an operator to 
make a service type 
available or unavailable 


Available or unavailable 



MT ser\dces are only assigned MT routing methods. MO services are only 
assigned MO routing methods. For ESME 202 provisioning, the SG 222 provides a user 
interface for ESME 202 provisioning and configuration reporting. At a minimum, die 
SG 222 provides the following configurable parameters for each ESME 202 as shown in 
Table 16: 



Parameter. . 


Description 


^ ^' Values !V 


ESME system id 


ESME system 
identification 
corresponding to the 
system_id parameter. 


Implementation specific 


ESME password 


Password for ESME 
corresponding to the 
password parameter. 


Implementation specific 


Authorized service 


List of services that the 
ESME is authorized to 
request deUvery of. 
These correspond to 
the service_type 
parameter. 


Implementation specific 


Throttle control 
limit 


The throtde control 
limit specifies the 
maximum number of 
messages per second an 
ESME is allowed to 
send to the SG. When 
this limit is exceeded, 
the SG invokes throtde 
for that ESME. 


Default = 1 msg/sec 
Minimum =0.1 msg/ sec 
Maximum = 500 
msg/ sec 


ESME permission 
state 


The ESME state allows 
an operator to allow or 
prohibit an ESME 
from binding to the 
SG. 


Allowed or prohibited 
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For MC provisioning, the SG 222 pro\ddes a user interface for MC provisioning 
and configuration reporting. At a minimum, the SG 222 provides the following 
configurable parameters for each MC 224i-224„ shown in Table 17: 



^ ^ ^ ^ Parameter, rj:^^' " 


C ''^ 7Pescr^3tio4;'" ^^-V 


y '\ :!y alues ; T^^^^^^t^^''' ^ ^ 


MC bind parameters 

1. System__id 

2. Password 

3. System_type 

4. Interface_versio 
n 

5. Addr_ton 

6. Addr_npi 

7. Address_range 


As specified in SMPP 
V3.4 protocol 
specification. 


Implementation specific 


MC message_id 
range 


Each MC has a unique 
range of values that are 
popvilated in the 

mCaSagC lU UjiXalllCtCi. 

The SG must maintain 
a mapping of 
message„id to MC to 
route query operations. 


Implementation specific 


MC availability 


iviv^ avaiiaDiiiiy aiiows 
an operator to make a 
MC available or 
unavailable. 




Flow Control Gao 
Timer 


Gap timer value for 
flow control when the 
MC indicates 
congestion. 


Minimum = 1 second 
Default = 60 seconds 
Maximum = 600 
seconds 


Message center ID 
(MCID) 


A unique three dig^t 
identifier associated 
with a MC for 
message__id mapping at 
the SG. 


Minimim = 000 
Maximum = 999 


Message ID 
mapping at SG 


Determines if the SG 
does message id 
mapping for this 
message center. 


On or Off 



We now turn to more details regarding anti-spamming according to the present 



invention. The D2 220 provides anti-spam check capability for MO and MT messages. 
For MT messages, spam is defined as the number of MT delivery requests for a specific 
MS 236 exceeding a predefined number widiin a specific time interval. For example, 
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spam for a particular service type may be defined as 20 deliver)^ requests widiin three 
minutes. For MO messages, spam is preferably defined as the number of MO delivery 
requests from a specific MS 236 exceeding a predefined number within a specific 
interval Other variations on how spam is defined may be provided as would be 
5 understood by one of ordinary skill in the art. 

The following description is based on the following assumptions: (1) From the 
SG 222 perspective, the D2 220 provides MDN-based anti-spam check capabilities; (2) 
For MT messages from e-mail addresses, a source address anti-spam check will have 
been performed before the message is delivered to the SG 222; and (3) For performance 
10 and capacity purposes, it is preferably assumed that 100% of MO message require anti- 
spamming (AS) check and 50% of MT messages require AS check. 

An interface between the SG 222 and die D2 220 will be used to perform die 
anti-spamming according to the present invention. With die details of the parameters 
and information disclosed herein, the appropriate interface between die SG 22 and die 
15 D2 220 may be implemented by those of skill in the art. 

An exemplary anti-spam algorithm will next be described. The D2 220 contains 
a list of barred MDNs. A MDN becomes barred if: 

1. The MT anti-spam tfireshold for the MDN is exceeded; 

2. The MO anti-spam threshold for die MDN is exceeded; or 

20 3. The MDN has been placed on die barred list by administrative action. 

The D2 220 provides a MT anti-spam direshold and a MO anti-spam direshold. 
The MT and MO anti-spam thresholds are configurable. Their configuration consists of 
a number of delivery requests and die associated time interval. When a MDN exceeds 
eidier anti-spam direshold (MT or MO), it is placed on die barred list for a specific 
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period of time, which may be referred to as the barred interval. When the barred interval 
expires, the MDN is removed from the barred list. The barred inten'-al is configurable, 
one value for MO and one value for MT with units of minutes, days, or permanent The 
D2 220 allows a MDN to be manually added to or removed from the barred list. When 
5 a MDN is added to the barred list manually, the user is given the option of applying the 
currently defined barred interval or permanently barring the MDN. 

The manner of performing an anti-spam check is next described. The D2 220 is 
capable of receiving an AS_Check qacry populated with destination__address, 
service__type, and replace_if„present_£lag(RIP). 

10 The RIP flag allows a message pending delivery at an MC to be replaced by a new 

message. For example, assume that a message for a specific MDN is pending delivery at 
the MC. A new message arrives for the MDN. Two actions are possible. First, the new 
message is added to the queue of messages for the MDN and, when available, the mobile 
receives all messages from the queue. Another possibility is to replace (RIP) the 

15 message, so that only one message is pending for a MDN at any one time. When 
combined with service type, RIP can be useful for delivering messages that are only 
valuable for a short period of time. For example, with weather reports, a subscriber 
would only want the most recent report, not all the ones that were missed. Therefore 
messages for this type of serice would use RIP. This also applies to messages used to 

20 program mobiles. E-mail messages would not use RIP because a subscriber wants to 
receive all of their e-mails, not just the most recent one. 

The D2 220 checks if the MDN in destination_address is on the barred list. If 
MDN is on the barred list, die D2 220 returns a "deny" in AS„Check_Resp. If the 
MDN is not on the barred list, the D2 220 returns an "allowed" in AS_Check_Resp. 
25 After receiving an AS__Check query and sending an AS_Check_Resp, the D2 220 updates 
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its MT anti-spam threshold counters for the MDN associated with the query. If the MT 
anti-spam threshold value is exceeded for the MDN, the D2 220 places the MDN on the 
barred list. 

A mobile originated message anti-spam check is next described. The D2 220 is 
capable of receiving a AS_Check query populated with destination_address, service_type, 
and source_address. The D2 220 checks if the MDN in source„address is on the barred 
Hst. If MDN is on the barred Ust, the D2 220 returns a "deny" in AS_Check_Resp. If 
the MDN is not on the barred list, the D2 220 returns an "allowed" in the 
AS_Check_Resp signal. After receiving an AS_Check query and sending an 
AS_Check_Resp, the D2 220 updates its MO anti-spam threshold counters for the 

MDN associated with the query. If die MO anti-spam threshold value is exceeded for 

die MDN, the D2 220 places die MDN on the barred list. 

The D2 220 does not require MDNs to be provisioned. The MDNs are added to 

the barred list based on queries received from the SG 222 or dirough administrative 

action. 

A transaction is defined as receiving an AS_Check query and responding widi an 
AS_Check_Resp. The D2 220 is capable of scaling to meet future capacity requirements 
for anti-spam checking of MT, MO, and total messages, as described in die following 
Table 18: 



■ Year- 


.mttpSI 


MO TPS 




1 


27 


1 


28 


2 


135 


15 


150 


3 


439 


56 


495 
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The D2 220 provides a utility to configure and report MT anti-spam threshold, 
MO anti-spam threshold, MT barred interval, MO barred interval, MDNs on barred list, 
and MDNs placed on barred list manually. The D2 220 also provides a utility to 
manually add or remove a MDN from the barred list, 

5 The mobile terminated (MT) message deHvery protocol, with an anti-spamming 

check, is next described. The ESME 202 submits messages for MT delivery using 
Submit_SM including service_type and destination_address (MDN). The SG 222 checks 
for the service_t}npe parameter in Submit_SM. If the service type has anti-spam check 
enabled, the SG 222 sends an 'AS__Check' message to die D2 220. The D2 220 checks 

10 the destination address, or mobile destination number (MDN) and service_type against 
anti-spam thresholds. For example, a query may indicate that thresholds have not been 
exceeded. If this is the case, the D2 220 returns status of 'allow' to the SG 222. The SG 
222 routes the Submit_SM signal to the destination MC 224i-224^. The destination MC 
224^-224^ returns a Submit_SM_Resp signal to the SG 222. The SG 222 also returns a 

15 Submit_SM_Resp signal to the ESME 202. The D2 220 then sends an Update signal to 
DUE Server 218 to update its anti-spam counters. The DUE Server 218 responds to the 
D2 220 with an Update_Resp signal containing the new status. 

The MT message delivery protocol for an unsuccessful anti-spam check is next 
described. The ESME 202 submits a message for MT delivery using the Submit„SM 

20 signal including service_type and destination_address. The SG 222 checks the 

service_type parameter in the signal Submit_SM. If the service type has anti-spam check 
enabled, the SG 222 sends an 'AS_Check' message to the D2 220. Parameters include 
service„type and destination_address (MDN). The D2 220 checks the MDN and 
service_type against anti-spam thresholds. If a query indicates that thresholds have been 

25 exceeded, the D2 220 returns status of 'deny' to the SG 222. The SG 222 sends a 
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Submit_SG_Resp signal with command_status set to 'service denied' to the ESME 202. 
The D2 220 sends an Update signal to the DUE Server 218 to update its anti-spam 
counters. Finally, the DUE Server 218 responds to D2 220 with an Update_Resp signal 
that contains a status. 

5 FIG. 7 illustrates the communicadon between an ESME 202, SG 222 and MC 

224j-224^ for MT message deHvery. An ESME 202 sends a Submit_SM signal to die SG 
222. The service_type parameter identifies die service to be delivered. The SG 222 
invokes routing method based on service_type and routing mediod dependent 
parameters to select destination MC. The primary destination MC 224^-224^ is selected. 

10 If primar}^ destination MC 224^-224, is not available, a secondary MC 224i-224^ is 

selected. If no MCs 224i-224, are available to deliver die service, die SG 222 returns a 
new error 'service type not available' in command_status. The SG 222 sends 
Submit_SM to destination MC 224i-224,. The destination MC 224i-224, repHes widi a 
Submit_SM_Resp signal The messagejd parameter uniquely identifies die message and 

15 die MC 2243-224, that sent die message. The SG 222 sends Submit_SM_Resp to die 
ESME 202. 

The replacejf_present_flag (RIP) parameter is an optional parameter in 
Submit_SM and Submit_Multi. If die RIP option is included, die ESME 202 may send a 
Submit_SM or Submit_Multi signal to die SG 222 widi replace_if„present_flag set to 
20 'Replace'. 

A message that includes die RIP flag indicates diat diis message should replace 
any message pending (for a specific mobile) delivery at the MC. If a message is received 
widi the RIP flag set and a message is pending at die MC 224^-224,, die existing message 
(if there is one) is replaced. In diis manner, die old or existing message is deleted. 
25 Therefore there is only one message pending for a mobile at any one time. 
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For the RIP operation to work appropriately in the context of the present 
invention, the message must be routed using a deterministic routing method. A 
deterministic routing method is one that routes messages with the same service type and 
destination address to the same MC 224^-224^. All messages for the same service type 
5 and destination address must route to the same destination MC 2243-224^ so it can be 
determined at the MC 224^-224^ if a message is pending and needs to be replaced as 
specified by the RIP flag. 

The SG 222 invokes a routimg method such diat a message is delivered to die MC 
224j-224x that originally received die message. The primary destination MC 224^-224^ is 
10 selected. Some routing mediods do not support RIP. If die MC 224, -224^ that 

originally received the message is not available, then the message is sent to the secondary 
MC 224i-224^ defined for the service. The original message will not be replaced. 
However, the new message wiQ be delivered. Thus, the subscriber may receive the same 
message twice. AH other steps are the same as described above. 

15 The message flow for Data_SM is the same as for Submit_SM described 

previously. The RIP is not a valid parameter in the Data_SM parameter. The Data_SM 
parameter may be used for interactive services. 

MT service using the parameter Submit_Multi will now be described. An ESME 
202 may use Submit„Multi specifying up to 254 destination addresses. The 

20 dest_address(es) parameter contains either the destination addresses or a Distribution 
list Name. The distribution list name is a file containing the destination addresses. The 
Message flow for Submit_Multi is the same as for Submit„SM described previously. 
RIP is a valid parameter in Submit_Multi. Routing is based on the first destination 
address in the dest_address(es) parameter. For this approach to support RIP, the 

25 destination address list must be in the same order for each message to get routed to the 
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correct MC 224i-224^. To support the distribution list, name-only routing to a specific 
MC 224j-224, is supported. 

The present invention protects the MCs 224i-224, and wireless network from 
undesirable or abusive messaging practices by providing address flow control and anti- 

5 spam checking. The objective of flow control is to protect the messaging complex 216 
and wireless network from undesirably high MT message traffic. Each ESME 202 has a 
maximum number of messages it is authorized to send to the SG 222 in a specific period 
of time. If the limit is exceeded, service is temporarily suspended. All messages received 
from the ESME 202 during the suspension period are rejected with a command_status 

10 indicating throttling. 

The objective of anti-spam checking is to protect die messaging complex 216 and 
wireless network by prohibiting an unreasonably high number of messages from being 
sent to or received from a specific MS 236 in a short period of time. If the number of 
messages sent to or received from a specific MS 236 in a specific time interval is 

15 exceeded, then subsequent message delivery requests for that MS 236 are rejected for a 
configurable time interval 

Flow control may also be applied to MT services. Anti-spam is preferably 
applied to MT and MO services. For each service type, the SG 222 maintains a flow 
control limit and anti-spam check (ASC) required parameter. The flow control limit is the 

20 maximum niimber of messages that an ESME 202 is allowed to send to the SG 222 in a 
specific time interval. The ASC parameter identifies whether messages for the service 
type require anti-spam check. 

The present invention provides MT flow control between an ESME 202 and the 
SG 222. This is illustrated in FIG. 8. The ESME 202 sends Submit_SM to die SG 222. 

25 The SG 222 determines that ESME 202 has exceeded its flow control limit. The SG 222 
returns Submit„SM_Resp with command_status set to existing error code Throttling 
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error - ESME has exceeded allowed message limits'. Any SMPP message received from 
the ESME 202 during the suspension inter\^al is rejected widi the same dirotding error 
message. 

Regarding anti-spamming, die existing Detect Undesirable Email (DUE) 
5 capabiHty is enhanced to support queries from the SG 222. This capability is referred to 
herein as the D2 220. For MT messages, spam is defined as the number of MT delivery 
requests for a specific MS 236 exceeding a predefined number within a specific time 
interval. For example, spam for a particular service type may be defined as 20 delivery 
requests within three minutes. For MO messages, spam is defined as the number of 
10 MO delivery requests from a specific MS 236 exceeding a predefined number widiin a 
specific interval. 

The major functions of the D2 220 are: (1) Receive a query from die SG 222 
containing the service type, source address and destination address; (2) For an MT 
service, the D2 220 updates its message delivery request counters for die MDN 

15 contained in the destination address parameter. If the number of deliver}^ requests have 
been exceeded for die time inter\-al, then the D2 220 returns a status of 'deny'. 
Otherwise, the D2 220 returns a stams of 'allow'; (3) For an MO service, die D2 220 
updates its message deliver}^ request counters for the MDN contained in the source 
address parameter. If die niomber of delivery requests have been exceeded for the time 

20 interval, then the D2 220 returns a status of 'deny'. Odierwise, die D2 220 returns a 

status of 'allow'; and (4) die D2 220 maintains a list of denied MDNs. If die MDN is on 
the denied list, the D2 220 returns a status of 'deny'. 

FIG. 9 illustrates an exemplary protocol for communicating between an ESME 
202, SG 222, D2 220, MC 224j-224, and MSG 232 for a mobile originated message 
25 where the system has an anti-spam check. We will first discuss an example of when die 
anti-spam check is successftol. The MC 224,-224, receives an SMDPP signal for MO 
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teleservice for delivery beyond the wireless network. The MC 224^-224^ sends 
Dehver_SM including service_type and source„address parameters to the SG 222. The 
SG 222 checks service_t}pe parameter in Deliver_SM. If service type has anti-spam 
check enabled, the SG 222 sends an ^AS_Check' message to the D2 220. Parameters 

5 include service_type and source.address (MDN). The D2 220 checks the MDN and 
service_t}^e against anti-spam thresholds. Assume for this example that a query 
indicates that thresholds have not been exceeded. The D2 220 returns status of 'allow' to 
die SG 222. The D2 220 updates counts for MDN and service_type based on data 
received in AS_Check and time received. The SG 222 routes a Deliver_SM signal to die 

10 destination ESME 202. The ESME 202 returns a Deliver_SM_Resp signal to die SG 
222, which returns the DeUver_SM_Resp signal to die MC 224^224,. 

Next, we will discuss the example process when the anti-spam check was 
unsuccessful. The MC 224^ -224, receives die SMDPP signal for MO teleservice for 
deliver}^ beyond the wireless network. The MC 224^-224, sends a DeIiver_SM signal 

15 including service_type and source_address parameters to the SG 222. The SG 222 
checks service_type parameter in Deliver_SM. If the service type has anti-spam check 
enabled, die SG 222 sends 'AS_Check' message to die D2 220. The parameters sent 
include service_t>pe and source„address (MDN). The D2 220 checks source address 
(MDN) and service_type against anti-spam thresholds. Assume that a query indicates 

20 that thresholds have been exceeded. The D2 220 returns status of 'deny' to die SG 222. 
The D2 220 updates counts for MDN and service^type based on data received in 
AS_Check and time received. The SG 222 sends a Deliver„SM_Resp signal widi 
conMnand_status set to 'service denied' to MC 2241-224,,. 

A combination flow control and anti-spam logic 400 is illustrated in FIG. 10. 
25 The logic 400 of FIG. 10 applies for bodi MT and MO messages. For an MT message. 
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the SG 222 receives the MT message (404) and inquires whether the flow control limit is 
exceeded for the sending ESME (406). If yes, the SG 222 rejects the message and 
transmits a message that the flow control limit is exceeded (408). If the flow control 
limit for the ESME 202 is not exceeded (406), the process inqvdres whether the anti- 
5 spam procedure is enabled for that service type (410). If yes, an anti-spam query is sent 
to the D2 (412) and an anti-spam status is returned. If the anti-spam status is not 
allowed (414), the message is rejected and a response is provided diat the anti-spam limit 
is exceeded and service is denied (416). If the anti-spam stams is allowed, then the 
message is routed to the destination MC (418). 

10 For a MO message received by the SG 402, the logic proceeds to step 410, and 

queries whether the anti-spam service is enabled for the service type 410. If yes, an anti- 
spam query is sent to D2 (412) and an anti-spam status is returned. If the anti-spam 
status is not allowed (414), the message is rejected and a response is provided diat the 
anti-spam limit is exceeded and service is denied (416). If die anti-spam status is allowed, 

15 then the message is routed to the destination MC (418). 

The MT message processing logic 300 at die SG 222 is shown witii reference to 
FIG. 11. The performance reqiairements for MT message processing logic are that die 
ST 222 has a response time of 100ms if no D2 220 query is required. The response time 
is defined as the time between receiving a PDU and subsequendy routing and sending 
20 the PDU to its destination. The SG 222 also imposes not more tiian 125ms latency if a 
D2 220 inqxiiry is required. Latency for dais purpose is defined as the time between 
receiving a PDU and subsequendy routing and sending die PDU minus die D2 220 
response time. 

FIG. 1 1 is intended to describe die required message processing logic and not to 
25 dictate specific implementation details. When die SG 222 receives (302) a Submit_SM, 
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Data_SM, or Subndt_Multi PDU from an ESME 202, it checks the bind state (304) of 
the sending ESME 202. If die ESME 202 is not bound, die SG 222 rejects die message 
(306) and returns the appropriate error code in die response PDU (342). The SG 222 
dien waits for die next message 348. If die ESME 202 is bound, when die SG 222 

5 receives a Submit„SM, Data_SM, or Submit.Multi PDUs from an ESME 202, it verifies 
that the ESME 202 is authori2ed to request delivery of die service identified by the 
service_type parameter (308). If die ESME 202 is not audiorized to request delivery of 
die service identified by the service_type parameter, die SG 222 rejects die message and 
responds to die ESME 202 widi a command_status of ESME Not Audiorized for 

10 Service Type in the Submit_SM_Resp, Data_SM_Resp, or Submit_Miilti_Resp PDUs 
(310). Then the SG 222 waits for die next message (348). 

ESMEs 202 are allowed to send messages to die SG 222 at a maximum rate. 
Messages in excess of die maximum rate are subject to tiirotde control by the SG 222. 
Throtde control enables the receivorship 200 to control die messaging traffic dirough 

15 the system according to the system capabilities and available resources, A sliding 

window algorithm is used to limit an ESME 202 to a maximum message delivery rate. 
When die SG 222 receives a PDU from an ESME 202, it verifies diat die ESME 202 has 
not exceeded its audiorized throtde control limit (312). If die ESME 202 exceeds its 
throtde control limit, the SG 222 rejects die message and responds to die ESME 202 

20 with a command_status of Throttling Error (ESME has exceeded allowed message 
limits) in die response PDU (314, 342). The SG 222 dien waits for die next message. 
All messages received from an ESME 202 in excess of die throtde control limit are 
rejected by the SG 222 with a command_status of Throtding Error. None of the excess 
messages are routed to a destination MC 224^-224^. The message flow diagrams 

25 according to FIG. 1 1 may also apply to die Submit„Multi and Data_ SM PDUs. 
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The SG 222 logs all throtde control events to the event log. The minimum 
information pro%dded includes time, ESME 202 subject to throtde control, number of 
messages rejected, and throtde control limit. Additional information may also be 
provided. 

The SG 222 may issue an alarm at step 314 when dirottle control is invoked for 
an ESME 202. The ESME 202 flow control alarm contains, at a minimum, time, ESME 
202 subject to throttle control, number of messages rejected, and throtde control limit, 
plus other information if desired. 

The logic process shown in FIG. 11 also involves an anti-spam check. The 
AS_Check and AS_Check_Resp are logic messages exchanged between die SG 222 and 
the D2 220. When die SG 222 receives a Submit_SM, Data_SM, or Submit_Multi PDU 
from an ESME 202 with a service_type defined to reqioire an anti-spam check (316), the 
SG 222 sends an AS_Check request (318) to die D2 220. For MT services, die 
AS_Check qatxy contains the service_type, source_addr (if present), destination_addr, 
and replace-if-present indicator. If the AS_Check_Resp (320) has a value of deny, die 
SG 222 shall reject the message and respond to die ESME 202 witii a command_status 
of Service Denied in die Submit_SM_Resp, Data_SM_Resp, or Submit__Multi_Resp 
PDUs (322). If die AS_Check_Resp (320) has a value of allow, die SG 222 routes die 
Submit_SM, Data_SM, or Submit_Multi PDU to die destination MC (324). 

If the D2 220 is unavailable, the SG 222 applies die anti-spam unavailable default 
action defined for the service type. The default action defined for each service type can 
be set to aUow or deny. If set to allow, then all messages requiring an Anti-Spam check 
are routed to the destination MC 224,-224, when die D2 220 is unavailable. If set to 
deny, then all messages requiring an Anti-Spam check are rejected witii a 
command_status of Service Denied. 
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If the D2 220 is unavailable and the anti-spam unavailable default action defined 
for the sendee tj^e is set to allow, the SG 222 routes aU messages requiring an 
AS.Check as if the AS_Check_Resp returned allow (320, 324). If the D2 220 is 
unavailable and the anti-spam unavailable default action defmed for the service type is set 
5 to deny, the SG 222 routes all messages requiring an AS_Check as if the 
AS_Check_Resp retxirned deny (320, 322). 

The SG 222 logs all D2 220 outages to the event log. The minimum information 
provided includes time and reason for outage, plus additional information if desired. The 
SG 222 may issue an alarm when the D2 220 becomes unavailable. The D2 220 
10 unavailable alarm contains, at a minimum, time and reason for outage, plus additional 
information may be provided. 

The SG 222 issues a clearing alarm when the D2.220 becomes available. The 
minimum information provided includes tune and indication that the D2 220 is available. 
Additional information may be provided. The SG 222 logs when the D2 220 becomes 
15 available after an outage. The minimum information provided shall include time and 
indication that D2 220 is available, plus additional information may be provided. 

If die MT message successfully completes bind check, service authorization 
check, throtde control check, and anti-spam check, the SG 222 invokes the routing 
method (324) for the service identified by the service_type parameter. The SG 222 sends 

20 die Submit_SM, Data_SM, or Submit_Multi PDU to die MC 224i-224, identified by die 
routing method to determine whether the identified MC 224^-224^ is available for the 
service type (326). The SG 222 receives die Submit_SM_Resp, Data_SM„Resp, or 
Submit_Mialti_Resp PDU from the destination MC 224^-224^ and subsequendy sends it 
to die originating ESME 202 unaltered. The SG 222 responds to die ESME 202 widi a 

25 command_status of Service Type Not Available in the Submit_SM_Resp, 
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Data_SM_Resp, or Submit_Multi_Resp PDUs if the SG 222 cannot route a message to a 
MC 224,-224, because aU MCs 224^224, defined to deHvery die service__t>T)e are 
unavailable (328). The SG 222 issues an alarm when a MT Service Type is not available 
(328). The minimum information provided in the alarm includes the time, Sendee Type, 
5 and indication that MT Service Type is unavailable, plus other information may be 
provided. 

The SG 222 logs when a MT Service T}^e becomes unavailable. The minimTim 
information provided includes the time, Service Type, and indication that MT Service 
Type is unavailable. Other information may be provided. The SG 222 issues a clearing 
10 alarm when a MT Service Type becomes available. The minimum information provided 
includes the time, Service Type, and indication tiiat MT Service Type is available plus 
other information. 

The SG 222 also logs when a MT Service Type becomes available. The minimum 
information provided includes time, Service Type, and indication diat MT Service Type is 

15 available and optionally other information. The SG 222 logs all occurrences of when the 
Service Type Not Available command_status is returned to an ESME 202 (MT service 
type not available). The minimum information provided includes time, service type that 
could not be routed, and source ESME, Other information may be provided. The SG 
222 responds to the ESME 202 with a command_status of Invalid Service Type in die 

20 Submit„SM_Resp, Data_SM_Resp, or Submit.Multi„Resp PDUs if die service^type 
parameter contains an unrecognized or iindefined service type value. 

If die identified MC 224|-224, is available for die service type (326), the process 
includes inquiring whether die MC 224i-224^ is subject to flow control and whedier no 
alternate MC 224,-224, is avaHable (330). If yes, die MC 224,-224, is subject to flow 
25 control and no alternate MC 224,-224, is available, and if congestion exists, die message 
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is rejected (332) and a response is sent back (342) to the originating ESME 202. The SG 
222 then waits for the next message (348), If die MC 224^224, is subject to flow control 
and an alternate MC 224i-224, is available (330), die message is routed to die destination 
MC (334). A response from die destination MC 224^-224, is sent (344). An MC 224i- 
5 224^ can initiate flow control by returning a command_status of Congestion (346). If die 
MC 224i-224^ response indicates congestion (346), and an alternate MC 224^-224^ is 
available (336) for die service type, the SG 222 will route die message to die alternate 
MC 224^-224, as die destination MC (334). If an alternate MC 224^-224^ is not available 
(336), the SG 222 returns die Congestion command_status to die originating ESME 202 
10 and invoke flow control (338). The message is rejected due to congestion at die MC 

(340). A response is sent back (342) to the originating ESME 202 and die SG 222 waits 
for the next message (348). Flow control in this case is described more fully below in 
connection with FIG. 12. 

If no test for congestion is desired, then step 346 shown in FIG. 1 1 may be 
15 omitted. In this case, the down-stream processes 336, 338 and 340 may be removed 
from FIG. 11 since following the received response from the destination MC 224^ -224^ 
in step 344, the process proceeds direcdy to sending a response signal to the originating 
ESME 202 in step 342. 

FIG. 12 illustrates in more detail the flow control message sequence discussed 
20 above in FIG. 11. FIG. 12 shows two scenarios: (1) an MT message, with a congested 
MC 224i-224^ and no alternative MC 224r224, available and (2) an MT message, die MC 
224^-224^ is congested, and an alternate MC 224i-224^ available. We will begin witii die 
first scenario. The ESME 202 submits a message for MT delivery using Submit^SM 
including service_type and destination„address. The SG 222 routes Submit__SM to 
25 destination MC 224^-224,. The MC 224^-224, returns Submit_SM_Resp to SG 222 widi 
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command^status of congestion. No alternate MC 224^-224^ is defined or available for 
the service„t}?pe. The SG 222 returns a Subniit_SM_Resp signal to the ESME 202 with 
a conimand_status indicating congestion. The SG 222 invokes flow control for the MC 
224^224^^ that returned the coramand_status indicating congestion; The SG 222 returns 
5 comniand_status of Congestion for all messages received while MC 224i-224^ is subject 
to flow control. Next, suppose that the congestion at the MC 224^-224^ abates. Then, 
flow control is discontinued at MC 224i-224^ and normal message routing resumes. 

When flow control is invoked, the SG 222 waits for a predefined gap interval, 
defined by a gap timer, before sending another message to a congested MC 224^-224,^. 

10 Flow control remains in effect as long as the receiving MC 224|-224j, returns a 

Congestion command_status. If message delivery to the MC 224^-224,^ is successful, 
indicated by a command_stams other than Congestion, flow control is discontinued. 
While flow control is in effect for a MC 2241-224^, all messages received by the SG 222 
that would be routed to that MC 224^-224^ receive a response command^status of 

15 congestion. This indicates to the ESME 202 to invoke its flow control algorithm. 

The SG 222 will return a command_status of Congestion indicating that the 
ESME 202 should invoke flow control under the conditions described in Table 19: 



MT Routing ' 

^"/ilethod': t"^n 


'^ipported". 


t: iCdngestion Indication SLeimneci t<^!'ESME^r?' ^ 


MC Specific 


Yes 


1. If primary MC invokes flow control and no 
alternate MC is defined. 

2. If both primary and alternate MC (if defined) 
concurrendy invoke flow control. 


Load 
Balancing 


No 


1. If all MCs in group invoke flow control 
concurrendy. 


MDN Range 


Yes 


1. If primary MC for MDN range invokes flow 
control and no alternate MC is defined. 

2. If both primary and alternate MC (if defined) 
concurrendy invoke flow control. 


Equal 
Allocation 


No 


1. If all MCs in group invoke flow control 
concurrendy. 


ESN 


Yes 


1. If primary MC invokes flow control and no 
alternate MC is defined. 
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>MT Routing 
Method . 


: MP J 
Supported 


Congestion Indication Returned to ESMjE 






2. If both primar}^ and alternate MC (if defined) 
concurrently invoke flow control. 



Next, we will discuss the second scenario where an alternate MC 224i-224^ is 
available. In this case, the ESME 202 submits message for MT delivery using 
Submit_SM including service„type and destination_address. The SG 222 routes 
5 Submit_SM to the destination MC 224^-224,. The destination MC 224^-224^ returns 
Submit__SM_Resp to the SG 222 with command_status indicating congestion. An 
alternate MC 224^ -224^ is defined and available for the service_type. The SG 222 routes 
the Submit_SM to the alternate destination MC 224^-224^^. The alternate destination MC 
224|-224x returns a Submit_SM_Resp signal to the SG 222 indicating message accepted. 

10 The SG 222 returns Submit_SM„Resp to die ESME 202. 

When the SG 222 receives a Submit_SM_Resp, Data_SM_Resp, or 
Submit_Multi_Resp with a command_status of Congestion and an alternate MC 224|- 
224^^ is defined and available for the service type, the SG 222 routes the message to the 
alternate MC 224i-224,. When the SG 222 receives a Submit_SM_Resp, Data_SM_Resp, 

15 or Submit_Multi_Resp with a command_status of Congestion and an alternate MC 224^- 
224^ is not defined or available for the service type, the SG 222 returns the Congestion 
command_stams response to the ESME 202 . The SG 222 invokes flow control for the 
destination MC 2243-224^. The SG 222 starts a gap timer when flow control is invoked 
for a MC 224^-224,. While die destination MC 224^-224^ is subject to flow control while 

20 the gap timer has not expired, the SG 222 does not route any messages to the destination 
MC 224^-224^. While die destination MC 224i-224, is subject to flow control while die 
gap timer has not expired, the SG 222 responds to all messages routed to the destination 
MC 224i-224^ with a command_status of Congestion. When the gap timer expires, the 
next message received for the destination MC 2241-224^ is sent to the destination MC 
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224^-224,. If the destination MC 224^-224, responds witii Congestion in the response 
command„status, flow control continues. If the destination MC 224^ -224, responds with 
a command_status other than congestion, flow control is discontinued. 

The SG 222 issues an alarm when flow control is invoked for an MC 224r224,. 
5 The MC 224i-224^ flow control invoked alarm contains, at a minimum, time, MC 224i- 
224^ subject to flow control, whether messages were routed to an alternate MC 224^-224^ 
(if alternate MC is defined), or if congestion indication was returned to originating ESME 
202. Additional information may be provided. The SG 222 logs when flow control is 
invoked for a MC 224^-224^. The minimum information provided includes tiime, MC 
10 224i-224^ subject to flow control, whether messages were routed to alternate MC 224^- 
224, (if alternate MC is defined), or if congestion indication was returned to originating 
ESME 202 . Additional information may be provided. 

The SG 222 issues an alarm when flow control is discontinued for an MC 224|- 
224,. The MC 224i-224, flow control discontinued alarm contains, at a minimum, the 
15 time, MC 224^-224^ subject to flow control, duration flow control was in effect, and 
number of messages rejected during flow control. Additional information may be 
provided. The SG 222 logs when flow control is discontinued for a MC 224^-224^. The 
minimum information provided includes time, MC 224|-224j. subject to flow control, 
duration flow control was in effect, and number of messages rejected during flow 
20 control. Additional information may be provided. 

FIG. 13 illustrates exemplary message processing for a MO message. FIG. 13 
shows three different scenarios: (1) An MO message with no anti-spam; (2) an MO 
message with anti-spam check successful; (3) an MO message with anti-spam check 
unsuccessful. 

25 We first discuss an MO message with no anti-spamming performed. The MC 

224i-224^ receives a SMDPP signal containing a MO message. The SMDPP contains die 



TID, bearer data, source address, and destination address. The MC 224j-224^ sends 
Deliver_SM message to the SG 222 and the SG 222 invokes a routing metiiod based on 
service_type and destination_addr to select a destination ESME 202. If no ESMEs 202 
are available to deliver the service, the SG 222 returns an error of 'service type not 

5 available'. The MC 224^-224^ then resends the message to the SG 222 at a later time. 
The SG 222 sends Deliver_SM to the destination ESME 202. The destination ESME 
202 replies with Deliver_SM__Resp signal. The SG 222 sends a Deliver_SM_Resp signal 
to the MC 224j-224^. The replace_if„present_flag parameter is not used in Deliver_SM; 
therefore the RIP option may not be available for MO messages. 

10 The MC 224^224, may use Data.SM for delivering MO messages to the SG 222. 

Message flow for Data_SM is the same as for Delivery_SM described previously. RIP is 
not a valid parameter in the Data_SM signal. 

Next, we discuss the MO message delivery when the anti-spam check is 
successful. The MC 224i-224^ receives a SMDPP for MO telesentice for delivery beyond 

15 wireless network. The MC 224i-224^ sends Deliver_SM including ser\ace_type and 

source_address parameters to the SG 222. The SG 222 checks service_type parameter in 
Deliver_SM. If service type has anti-spam check enabled, the SG 222 sends 'AS_Check' 
message to the D2 220. Parameters include service_type and source_address (MDN). 
The D2 220 checks source address (MDN) and service_type against anti-spam 

20 thresholds. 

A qutry may indicate that thresholds have not been exceeded. The D2 220 
returns status of *allow' to the SG 222. The SG 222 routes Deliver„SM to the 
destination ESME 202. The ESME 202 returns Deliver_SM_Resp to the SG 222. The 
SG 222 returns to DeUver_SM_Resp to MC 224,-224,. The D2 220 sends Update to 
25 DUE Server 218 to update its anti-spam counters. The DUE Server 218 responds to D2 
220 with Update__Resp containing status. 
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Finally, with FIG. 13, we discuss the scenario where a MO message delivery 
occurs widi the anti-spam check unsuccessful The MC 224^224^ receives an SMDPP 
for MO teleservice for delivery beyond the wireless network. The MC 224i-224^ sends 
Deliver_SM including service_„type and source_address parameters -to the SG 222. The 
5 SG 222 checks service_type parameter in Deliver_SM. If service type has anti-spam 
check enabled, the SG 222 sends 'AS_Check' message to the D2 220. Parameters 
include service_type and source„address (MDN). The D2 220 checks die MDN and 
service_type against anti-spam thresholds. A query may indicate that thresholds have 
been exceeded. The D2 220 returns status of 'deny' to the SG 222. The SG 222 sends 
10 Deliver_SG_Resp with command_status set to 'service denied' to the MC 224,-224^. 

The D2 220 sends an Update to DUE Server 218 to update its anti-spam counters. The 
DUE Server 21 8 responds to D2 220 widi Update^Resp containing status. The message 
flow shown in FIG. 13 also applies to Data_SM PDU. 

MO message processing logic 500 at tht SG 222 is shown in FIG. 14. When the 
15 SG 222 receives a Deliver_SM or Data_SM PDU from an MC 224i-224„ it checks die 
bind state (504) of die sending MC 224^-224^. If die MC 224i-224, is not bound, die SG 
222 rejects the message (506) and indicates that die ESME 202 is not bound in the 
response to the originating MC (526). An appropriate error code is included in the 
response PDU. The SG 222 dien waits for die next MO message (528). 
20 When die SG 222 receives a Deliver_SM or Data^SM PDU 502 from an MC 

224|-224^ with a service_type configured to require an anti-spam check (508), the SG 222 
sends an AS_Check request to die D2 (510). For MO service types, die AS^Check 
query is populated with destination_address, service^type, and source_address 
parameters. If the AS_Check_Resp has a value of deny (512), the SG 222 rejects die 
25 message (514) and responds to die MC (526) widi a command_status of Service Denied 
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in the DeUver_SM„Resp or Data_SM„Resp PDUs. The SG 222 waits for the next MO 
message (528). 

If the MO message successfully completes bind check (504) and anti-spam check 
(512)(the anti-spam status is "allowed"), or if die anti-spam service is not enabled for the 

5 service type (508), the SG 222 invokes die routing metiiod (516) for die service identified 
by the service_type parameter. The SG 222 determines whether an ESME 202 is 
available for the service type (518). The SG 222 sends die Deliver_SM or Data_SM 
PDU to the ESME 202 identified by die routing mediod. The SG 222 receives die 
Deliver_SM„Resp or Data_SM_Resp PDU from die destination ESME 202 and 

10 subsequendy sends it to the originating MC 224i-224, unaltered. The SG 222 responds 
to die MC 224i-224^ with a command_status of Service Type Not Available in die 
Deliver„SM_Resp or Data_SM_Resp PDUs if die SG 222 cannot route a message to an 
ESME 202 because all ESMEs 202 defined to receive die service_type are unavailable 
(520). 

15 The SG 222 logs all occurrences of when die Service Type Not Available 

command_status is returned to an MC 224i-224, (MO service type not available). The 
minimum information provided includes time, service type that could not be routed, and 
source MC 224^ -224^. Other information may be provided. The SG 222 may issue an 
alarm (520) when a MO Service Type is not available. The minimum information 

20 provided includes the time, Service Type, and indication diat MO Service Type is 

unavailable. Other information may be provided. The SG 222 logs when a MO Service 
Type becomes unavailable. The minimum information provided includes time, Service 
Type, and indication that MO Service Type is unavailable, plus other optional 
information. 

25 The SG 222 issues a clearing alarm when an MO Service Type becomes available. 

The minimum information provided includes time, Service Type, and indication that MO 
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Sendee Type is available. Additional information may also be pro\dded. The SG 222 
logs when a MO Service Type becomes available. The minimum information provided 
includes time, Service Type, and indication that MO Service Type is available, plus other 
information may also be provided. 
5 If the response from the ESME 202 indicates tiiat it is available for the service 

type (518), the message is routed to the destination ESME (522) and a response is sent to 
the SG 222 from the ESNE 202 indicating tiiat die message was received (524, 526). 
Finally, the SG 222 waits for the next MO message (528). The SG 222 responds to die 
MC 224^-224^ with a command_status of Invalid Service Type in die Deliver_SM_Resp 
10 or Data_SM_Resp PDUs if the service_type parameter contains an unrecogni2ed or 
undefined service tj^e value. 

We now turn to the cancel operation according to the present invention. This is 
illustrated in FIG. 1 5. A cancel operation is used by an ESME 202 to cancel one or 
more pre\dously submitted messages. A specific message can be canceled based on the 
15 message Jd and service_type parameters. A set of messages can be canceled using the 
service_type and destination_address parameters. FIG. 15 illustrates the cancel message 
procedure between an ESME 202, die SG 222, and die MC 224^-224,. 

To cancel a single message, the ESME 202 sends a CanceLSM to the SG 222. 
The messagejd parameter is popiilated with die message_id returned in the original 
20 Submit_SM, Data_SM, or Submit_Multi message. The SG 222 routes die CanceLSM to 
the MC 224^-224^ tibat received die original message. The messagejd parameter 
uniquely identifies the MC 224i-224^ tiiat originally received die message. Note diat not 
all routing methods support canceling messages. If die MC 224^-224^ diat originally 
received the message is not available, tiien die SG 222 returns a new error code 'Service 
25 type not available' in command_status. The destination MC 224^-224^ replies with 
CanceLSM_Resp. The SG 222 sends CanceLSM_Resp to die ESME 202. 
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To cancel all messages previously submitted for a specific destination address and 
service type, the ESME 202 sends a CanceLSM to the SG 222. The message Jd 
parameter is set to null; the service_type is set to the service type of the messages to be 
cancelled. The destination_addr is set to the destination addresses t)f the messages to be 

5 canceled. The SG 222 routes the CanceLSM to die MC 224r224, that received tht 
original messages. Routing is based on service_type and destination_addr. If the MC 
224^-224^ that originally received message is not available, then the SG 222 returns a new 
error code *Sendce type not available' in command_status. The destination MC 224i- 
224^ replies with CanceLSM_Resp. The SG 222 sends a Cancel_SM_Resp signal to the 

10 ESME 202. 

Next, the replace oprarion is described with reference to FIG. 16. The replace 
operation is used by an ESME 202 to replace a previously submitted message that is 
pending delivery. An ESME 202 sends a Replace_.SM signal to die SG 222. The 
message_id parameter is populated with the message_id returned in the original 

15 Submit^SM, Submit_Multi message. The ESME 202 retains die messagejd returned in 
the original message. The SG 222 routes die Replace_SM to die MC 224^-224^ diat 
received the original message. The messagejd parameter uniquely identifies the MC 
224i-224, that originally received die message. If die MC 224i-224^ diat originally 
received message is not available, tiien die SG 222 returns a new error code 'Service type 

20 not available' in command_status. The destination MC 224^-224^ replies with 

Replace_SM_Resp containing message status. The SG 222 sends Replace_SM_Resp to 
die ESME 202. 

FIG. 17 shows an example of a check link status inquiry. In diis case, die ESME 
202 inquires regarding die link between die ESME 202 and die SG 222. The SG 222 may 
25 send Enquire_Link to the MC 224|-224^ to check die application level communications 
link between tiie SG 222 and die MC 224^-224,. The MC 224^-224, responds widi 
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Enquire_Unk_Resp. The ESME 202 may send Enquire„link to the SG 222 to check 
the application level communications link between the ESME 202 and the SG 222. the 
SG 222 responds with Enqiiire_Link_Resp. 

FIG. 18 illustrates the alert notification protocol used by die MC to notify an 
5 ESME 202 diat an MS 236 has become available. The ESME 202 sends a Data_SM 
signal to die SG 222 with set„dpf set for delivery failure request. The SG 222 routes 
Data_SM to destination MC 224i-224,. Tlie MC 224^ -224, attempts message deUvery. If 
the MS 236 is not available, die MC 224,-224, returns Data_SM_Resp to ±e SG 222 
indicating the dpf_stams. The SG 222 sends Data_SM_Resp to die ESME 202 
10 indicating die dpf_status. At some later time, die MC 224i-224, successfully delivers die 
message to die MC 224,-224,. The MC 224,-224, sends Alert_Notification to die SG 
222 indicating dpf_status. The SG 222 routes Alert_Notification to die ESME 202 using 
the esme_addr parameter. 

Over-the-air activation is also available with die introduction of the SG 222 into 
15 die messaging complex 21 6. FIG. 19 iUustrates an example activation message flow 

according to the present invention. An OTAF sends a Submit__SM signal to the SG 222. 
The MS 236 number assignment module (NAM) data is contained in die short_message 
parameter. The NAM data associates die mobile identification number (MIN) widi die 
electronic serial number (ESN). The destination_address parameter contains activation 
20 MIN. For an Initial Over the Air Activition (lOAA), die SG 222 extracts die electronic 
serial number (ESN) from the MS NAM data in die short„message parameter. The 
lOAA process refers to the first dime a phone is activated over die air. During lOAA, 
parameters are downloaded to die phone allowing it to operate in the wireless network. 
For example, die phone receives its MDN (phone number) along widi otiier parameters 
25 required for it to operate in the network. 
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Routing is based on odd or even ESN value. The SG 222 routes Subtnit_SM to 
the destination MC 224i-224, based on the ESN value. If an MC 224i-224, is not 
available, the SG 222 returns 'service not available' in command.status. The MC 224j- 
224^ responds with Submit_SM__Resp with a unique messagejd. The messagejd can 
5 subsequendy be used to query or cancel request from the OTAF. The SG 222 sends a 
Submit_SM_Resp signal to the OTAF. The MS 236 registers with activation MIN at the 
MC 224r224,. A REGNOT signal is routed to die MC 224,-224, by STP based on odd 
or even ESN value. Then lOAA can occur using existing procedures. 

For the operation of reprogramniing over-the-air-activation (ROAA), the OTAF 
10 sends a Submit_SM signal to the SG 222. The MS NAM data is contained in die 

short_message parameter. The destination_address parameter contains die MIN of die 
MS 236. Then the steps from die SG 222 extracting die ESN dirough the SG 222 
sending the Submit_SM_Resp to OTAF signal are die same as die lOAA above. 

The MC 224,-224, sends a SMSGEQ signal to die HLR 226. The HLR 226 
15 responds with a SMSGEQ signal containing die SMS_Address. If die MS 236 is not 

registered, the standard delivery pending and SMSNOT procedxires apply. Then, ROAA 
can be accomplished using existing procedures. 

At die MC 224,-224, providing OTAP, RIP is set to 'replace' globally. Any 
pending activation (lOAA or ROAA) for a specific destination_address is replaced 
20 regardless of the RIP parameter in Submit_SM. The SG 222 must route lOAA and 
ROAA requests for die same MS 236 to die same MC 224,-224, so pending messages 
can be replaced if present The RIP is based on destination_address. The Destination 
address is the activation MIN for lOAA and MIN for ROAA. Therefore, die SG 222 
routing is based on ESN not MIN. 
25 The SG 222 will have certain functions diat it performs. These include security, 

anti-spam and flow control, and ESME - SG flow control. Regarding security issues, die 
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ESMEs 202 will communicate with the SG 222 using dedicated network connections. 
The SG 222 is not connected to die Internet, The SG 222 implementation and 
communication with ESMEs 202 must meet established security requirements. The 
ESME 202 must be authorized to bind to die SG 222. Parameters for binding include 
5 System ID, specific socket, and password. The ESME 202 must be audiorized to 

request delivery of a specific service type. The ESME 202 must be audiorized for each 
service type it is allowed to delivery. An ESME 202 may be audiorized to deliver more 
than one service type. If the ESME 202 requests delivery of a service type for which it 
is not authorized, the request will be rejected. Encryption of messages between ESME 
10 202 and SG 222 should not be required. 

Having discussed the various functions of the SG 222, we now turn to FIG. 20, 
wherein example hardware reqiiirements for the SG 222 are disclosed. The main 
components of the SG 222 include at least one switch and at least one router. The 
ESMEs 202 transmit messages through an IP network 250 to die SMPP gateway 222. 
15 The SMPP gateway 222 comprises at least two routing servers, such as die Sun 

Microsystem Netra T 1400 Dual 440 MHz processor servers widi 1GB memory and two 
1 8 GB disks. The SG 222 is scalable from 2 to n routing nodes 264^ - 264„. Odier 
more current computer servers may also be used and are contemplated as within the 
scope of the invention. Other features such as slots for removable media devices and 
20 other standard equipment are well known to those of skill in the art. 

The servers control at least one and preferrably two Cisco Local Director Routers 
252, 254 as switches. Preferrably, TCP/IP is die networking protocol to provide 
communication across the diverse networks. Each switch 252, 254 preferrably contains a 
primary 256, 260 and a secondary 258, 262 component, respectively, for controlling die 
25 destination of each message received from die IP network 250. The destination of each 
message from the primary 256, 260 or secondary 258, 262 components of die switches 
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252, 254 is a first routing node 264, or a second routing node 2642, up to "n" routing 
nodes. These routers are preferrably Cisco Local Director Routers comprising 
LocalDirector 420, a four port 10/100 Ethernet card in a rack-mounted arrangement. 
The routers 264^, 2642 ^oute the messages to die appropriate message center 224^, 2242, 
5 or 224^. While specific hardware components are mentioned as preferable, this is not 
meant to Umit the general components to any type of router, computer server, or switch 
that performs the functions disclosed herein for the SG 222. 

Although the above description may contain specific details, they shodd not be 
construed as limiting the claims in any way. Odier configurations of die described 
10 embodiments of the invention are part of the scope of diis invention. For example, the 
above description discusses messages being passed between an ESME and a wireless 
device. However, the SG may be modified to route messages between wireless carriers. 
Thus, messages may be passed from a subscriber of one wireless carrier to a subscriber 
of another carrier for botii MO and MT messages. Accordingly, the appended claims 
15 and their legal equivalents should only define the invention, rather than any specific 
examples given. 
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CLAIMS 

We claim: 

1. A method of controlling a message sent from a message source to a message 
5 receiving device using a gateway, the method comprising: 

transmitting a data unit associated vnth the message from the message source to 
the gateway; 

determining whether the message source has exceeded a threshold value 
associated with sending messages; and 
10 transmitting a response signal from die gateway to die message source indicating 

an error if the message source has exceeded the threshold value. 

2. The method of claim 1, furdier comprising: 

rejecting further messages transmitted from the message sovirce to the gateway 
15 when the determining step indicates diat die message source has exceeded the direshold 
value. 

3. The method of claim 2, wherein transmitting die response signal furdier 
comprises transmitting a command status signal indicating a throttling error. 

20 

4. The method of claim 3, further comprising: 

transmitting the message from the gateway to a destination message center if the 
determining step indicates diat die message source has not exceeded die direshold value. 

25 5. The metiiod of claim 4, further comprising: 
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logging in the gateway all events associated with determining whether the 
message source has exceeded the threshold value. 

6. The method of claim 5, wherein logging in the gateway all events associated with 
5 determining whether the message source has exceeded the threshoold value further 

comprises logging the time, message source subject to throttie control, number of 
messages rejected, and throtde control limit. 

7. The method of claim 3, farther comprising: 

10 signaling an alarm when the threshold limit is exceeded by a message source, 

8. The method of claim 7, wherein the alarm includes a time, a message source 
subject to throtde control, number of messages rejected, and threshold value. 

15 9. The method of claim 8, wherein the threshold value is a throtde control limit. 

10. The method of claim 3, wherein the command status signal indicating a throttling 
error further instructs the message source to reduce a message sending rate. 

20 11. The method of claim 9, further comprising: 

transmitting an alarm from the message source to the gateway after the message 
source receives the alarm indicating that the threshold limit is exceeded by a message 
source. 
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1 2. The method of claim 1 1 , wherein the alarm transmitted from the message source 
to the gateway further comprises a destination gateway name, a message rate when it 
received the throtde error signal, and a new message rate. 

5 

13. A method of providing throtde control in a gateway between a message source 
and a destination message center, the method comprising: 

receiving a message from a message source at the gateway; 

determining whether the message source has exceeded a throtde control limit; 

10 and 

transmitting a throttling error to die message source if the message source has 
exceeded the throtde control limit according to die determining step. 

14. The method of providing throtde control of claim 13, further comprising: 
15 reducing a message sending rate from die message source after receiving the 

throttling error. 

1 5. The method of providing dirotde control of claim 13, fiirther comprising: 
invoking throtde control if the message source has exceeded the throtde control 

20 limit according to the determining step. 

1 6- The mediod of providing dirotde control of claim 1 5, wherein dirotde control 
furdier comprises rejecting messages transmitted by die message source to the gateway 
while the message source is transmitrimg messages at a rate exceeding die dirotde control 
25 limit 
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17. The method of providing throtde control of claim 16, wherein the throtde 
control limit is approximately between 0.1 messages per second and 500 messages per 
second. 

5 18. The method of providing throtde control of claim 17, furdier comprising: 
storing a throtde control limit on a per message source basis in the gateway. 

19. The method of providing throtde control of claim 13, fiirdier comprising: 
routing the message to a message center if die determing step determines that the 

10 throtde control limit is not exceeded. 

20. The method of providing throtde control of claim 19, furdier comprising: 
logging all throtde control events to an event log. 

15 21. The method of providing dirotde control of claim 15, further comprising: 

issuing an alarm from the gateway to the message source when throtde control is 
invoked. 

22. The method of providing throtde control of claim 21 , wherein issuing an alarm 
20 further comprises providing a time, the message source subject to throtde control, a 

number of messages rejected and the throtde control Umit. 

23. The method of providing dirotde control of claim 22, furdier comprising: 
issuing a message source alarm from the message source to the gateway when the 

25 message source receives the throttling error. 



75 



24. The method of providing throtde control of claim 23, wherein the message 
source alarm pro^ddes a gateway name, a message rate of the message source when the 
throtde error was received, and a new message rate. 

5 25. A short message point-to-point gateway for controlling a volume of messages 
transmitted from a message source to a message-receiving device, the short message 
point-to-point gateway comprising: 

a receiving module diat receives messages transmitted from the message source; 
a determination module that determines whether the message source has 
10 exceeded a threshold value associated with sending messages; 

a transmitting module diat transmits a response signal to the message source 
indicating an error if die message source has exceeded the threshold value. 
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ABSTKACT OF THE DISCLOSURE 

A system and method is disclosed for providing throtde control in the context of 
a short message point-to-point gateway. The mediod enables the control of a message 
sent from a message source, such as an external source message entity (ESME) to a 
5 message-receiving device such as a mobile phone. The method comprises transmitting a 
data unit associated widi the message from die message sotirce to the gateway, 
determining whedier the message source has exceeded a direshold value associated with 
sending messages and transmitting a response signal from the gateway to the message 
source indicating an error if the message source has exceeded the threshold value. In diis 
10 manner, tiirottle control occurs on an ESME-by-ESME basis, rather than in the 
aggregate. 



77 



1/17 




FIG, 3 



3/17 



250 



bind - esme to sr 



202 



-X. 



Ill 



ESMF SMPP GATEWAY 



MC 



^224x 



Bind Transmitter - MT Service 



MT 

Service 



BInd_Transmitt(ir(systemJd, password 
systemjype.. 



Bind_TransmiHer_Resp(system_id-SR...) 



Bind Receiver - MO Service 



MO 
Service 



Bind_Receiver 
systemjype. 



[systemjd, pa: 
••) 



Bind_Receive ■_Resp(system_ 



sword 



d-SR...) 



S.T.P. 



228 



Bind_Transceiver - MT and MO Service 



MT and MO 
Service 



Bind_Transceiv(!r(systemJd, pfissword 
systemjype...) 



Bind_Transceiver_Resp(systemjd-SR...) 



FIG, 4 



4/17 



bind - sr to esme 



202 



-X- 



222 



ESMF SMPP GATEWAY 



^224x r 



228 



S.T.P. 



Bind Transmitter - MT Service 



MT 
Service 



MO 
Service 



Bind_Transmitt{!r(system_id, password 



systemjype. 



Bind_Transmitter_Resp(systemJd-MC...) 



For eacti MC defined for 



MT service 



In SR 



Bind Receiver - MO Service 



Bind_Receiver 
systemjype 



[sjstemjd, password 



Bind_Receiver_Resp(systemJd-MC 



For eacti MC 
MO service 



defined for 
in SR 



BindTransceiver - MT and MO Service 



MT and MO 
Service 



Bind_Transceivf!r(systemJd, pdssword 



systemjype. 



■■) 



BindJransceiver_Resp(systemJd-MC...) 



For each MC 
MT and MO service 



lefined for 
in SR 



FIG. 5 



5/17 



MT MESSAGE PROCESSING 
202, 



ESME 



SMPP GATEWAY 



111 



D2 



220 



218 



DUE SERVER 



MC 



^224x 



228 



S.T.P. 



MT MESSAGE, NO THROTTLE CONTROL, NO ANTI-SPAM 



MT 
SERVICE 



M 

SERVICE 



SUBMIT_SM(sei|vIce_type, 
destination_|addr...) 

Submit_SM(seh/ice_type, dest 



Submit_SM_Resp(message_id. 



Su )miLSM_Resp{nessage_Id...) 



•) 



nation_addr...) 



DELIVER MT MESSAGE 
IN WIRELESS NETWORK 



MT MESSAGE WITH ANTI-SPAM CHECK SUCCESSFUL 



Submit_SM( 
destination 



servicejype, 
3ddr...) 

AS_Check( 
destination 



Sub_SM_Resp(rnessage_id...) 



senficejype, 
]ddr...) 



AS_Checl<_Resp(status T^allow, 
Submit_SM(sen'ice_type, destiriation_addr...) 



Sul:imit_SM_Resp(niessage_id...) 



.) 



Update{servlce. 
destination 



ypdate_Resp(; 



DELIVER MT 
IN WIRELESS 



-type, 
) 

atus...) 



addr 



MESSAGE 
NETWORK 



MT MESSAGE WITH ANTI-SPAM CHECK UNSUCCESSFUL 



M 

SERVICE 



MT 
SERVICE 



Submit_SM_( 
destination 



s|ervice_type 
addr...) 

AS_Check(serv 
destination 



Submit_SM_Res 
('service deniec 



Submit_SM( 
destination 



cejype, 
dddr...) 



AS_Checl<-Resp (status=deny... 

Update(service 
destination 



MT MESSAGE WITH THROTtLE CONTROL INVOKED 



serivicejype, 
addr...) 



Submit_SM_Re!!p(command_st]tus=throttled 



) 



addr. 



Update_Resp(s 



type, 
...) 

atus...) 



6/17 

FIG. 6 



SERVICE TYPE 




ROUTING METHOD 




PRIMARY DESTINATION 














452^ 


454 


/ 






SECONDARY DESTINATION 

' S ' 




mmo DATA 


— 460 


458 



FIG, 7 



7/17 



GENERAL SEND MT MESSAGE 
202 



ESME 



MT 
SERVICE 



MT 
SERVICE 



MT 
SERVICE 



SMPP GATEWAY 



111 



MC 



a224x r 



228 



S.T.P. 



MT Using SubmiLSM 



Submit_SM(s 
destination 



service 



Submit_SM_ 
Resp(message. 



Jype. 

addr...) 
Submit_SM( 
destination 



Submit_SM_Re 



id...) 



seri/icejype, 
^]ddr...) 

sp(messQgeJd. 



DELIVER MT MESSAGE 
IN WIRELESS NETWORK 



MT Using Data.SM 



Submit_SM(ser/ice_type, 



destination 



]ddr...) 

Data_SM(serv 
destination. 



Data SM Re: 



pata_SM_Resp( messagejd...) 



DE 



ce_type, 
3ddr...) 

p(message_id.. 



) 



.IVER MT MESSAGE 



IN WIRELESS NETWORK 



Submit_MultI( 
dest_add 



MT Using Submit_Multi 



servicejype, 
relss(es)...) 

Submit_Multl( 
dest_addresi( 



Submit_Multi_F 
status...) 



Submit_Multi_ 
status...) 



esp(message_i(l 



DE 



s0rvice_type, 
es)...) 

Resp(message_ 



_d, 



LIVER MT MESSAGE 



IN WIRELESS NETWORK 



FIG. 8 



8/17 



MT FLOW CONTROL 



ESME' 


1 — 


SMPP GATEWAY 




MC 




S.T.P. 



228 



MT 
SERVICE 



Submit_SM(ser|vice_type, 
destination 



Submit_SM_ 
Resp(commanc 



addr...) 
_status=ttirottle|d...) 



FIG, 9 



GENERAL RCV MO MESSAGE WITH ANTI-SPAM 



202 



ESME 



SMPP GATEWAY 



222 ^220 



D2 

zn 



_^224x 



MC 



232 



MDC 



Anti-Spam Ctieck SUCCESSFUL 



Deliver_SM(ser 
destination. 


Deliver_SM(sen 
destination_< 


rice type, 
3ddr...) 


AS_Ctieck(sen 
source_addr... 


ice type, 

) 

>p(status=allow. 
sp(message_id. 


AS_Checl<_Re 


(Ticejype, 
addr...) 

jd...) 
Deliver_SM_R€ 


Deliver_SM_ 
Resp(message. 





SMDPP(TID, 
bearer data...) 

smdppQ 



.) 



MO 
SERVICE 



Anti-Spam Ctieck Falls 



Deliver_SM( 
destination.! 



seryicejype, 
]ddr...) 



AS_Ctieck(ser\ 
source_addr.. 



icejype, 



AS_Check_Resp(status=deny 
Deliver_SM_Resp('service denield 



SMDPP(TID, 
bearer data...) 

smdppQ 



MO 
SERVICE 



( SR RECEIVES MT MESSAGE ) 
^ESME BOUND? 

'ESMt 
AUTHORIZED FOR 
^ERVICETYPE?. 



10/17 300 JPJG, 11 

\ 



308- 



312 



fES 

ThrottlT 
tontrol limit exceeded: 

FOR ESME? 



NO 


REJECT MESSAGE, 






ESME NOT BOUND 








306 


NO 


REJECT MESSAGE, 
ESME NOT 






AUTHORIZED FOR 
SERVICEJYPE 


— 310 








YES 


REJECT MESSAGE, 
ESME THROHLE 
LIMIT EXCEEDED 






"--314 



-ANTI-SPAM 
ENABLED FOR SERVICE 
316>^\TYPE? 



318 



YES 


SEND ANTI-SPAM 




QUERY TO D2 



INVOKE MT ROUTING METHOD 
FOR SERVICEJYPE 




REJECT MESSAGE, 
ANTI-SPAM LIMIT 
EXCEEDED SERVICE 
DENIED 



ROUTE ME 
DESTINAl 


SSAGE TO 
nON MC 




^344 


RECEIVE RESPONSE FROM 
DESTINATION MC 




INVOKE FLOW 
CONTRO L FOR MC 
338^^^ 



REJECT MESSAGE, 

CONGESTION AT MC 
1 



SEND RESPONSE TO 
ORIGINATING ESM E 

WAIT FOR NEXT 
MT MESSAGE 



FIG. 12 



11/17 



GENERAL RCV MO MESSAGE WITH ANTI-SPAM 



ESME 



202 



SMPP GATEWAY 



111 



D2 



220 



_^224x 



MT 
SERVICE 



MT 
SERVICE 



MC 

"~r~ 



-X- 



228 



S.T.P. 



MT MESSAGE, MC CONGESTED, NO ALTERNATE MC AVAILABLE 



Submit_SM( 
destination 



seryicejype, 
(iddr...) 



Submit_SM_Ri3sp(Congestion. 



Sijbmit_SM( 
destination 



Submit_SM_Re^p 
(Congestion...) 



Submit_SM( 
destination 



Submit_SM(ser|/ice_type, destipotion.addr...) 

^ ) 
CONGESTTION 



Submit_SM_R(isp(Congestion 



seryicejype, 
oddr...) 

FLOW 
CONTROL 
INVOKED 
FOR MC 



Submit_SM_Re 



Submit_SM_Resp(messageJd. 



seryicejype, 
fddr...) 

Submit_SM(sertviceJype, desti|nation_addr...) 



sp(messagejd. 



DELIVER MT MESSAGE 
IN WIRELESS NETWORK 



MT MESSAGE, MC CONGESTED, ALTERNATE MC AVAILABLE 



Submit_SM(sep 
destination_( 


Mcejype, 
]ddr..,) 

Submit_SM(sen 
destination_( 


'icejype, 
^ddr...) 


Submit_SM_Re 


Submit_SM_Rf 


!sp(Congestion.. 


Submit_SM(ser 
destination. 


/icejype, 
]ddr...) 


Submit_SM_Re 


sp(messagejd. 


sp(messagejd. 


.) ^ 

II 

1 





FIG, 1 3 



12/17 



MO MESSAGE PROCESSING 
202. 



'222 



ESME'^ SMPP GATEWAY 



220 



02 



218 



DUE SERVER 



MC 



228 



S.T.P. 



MO MESSAGE, NO ANTI-SPAM 



Deliver_SM(serv|i^ce_type, 
source_aadr,.. 



SMDPP(TID 
Deliver_SM(^ericeJype. soi|irce_adclr...) 



) 



Deliver_SM_Re)p(messageJd. 

Deli 



^er_SM_Resp(mfessage_id...) 



bearer data...) 



smdppQ 



MO 
SERVICE 



MO MESSAGE WITH ANTI-SPAM CHECK SUCCESSFUL 



T 



Deliver_SM(ser\iifeJype, 
source addr... 



Deliver_SM_Re 



Deliver J M(service_type, 



AS_Check(sen 
source_addr...) 



AS_Check_Re:sp(status=allow 



) 



icejype, 



;p(messagejd. 

Deliver_SM_Reip(messag€jcl. 



Update(service 
destination. 



ypdate_Resp(s 



SMDPP(TID 
ource_addr...) 



) 



-type, 

••) 

atus...) 



addr, 



bearer data...) 



smdppO 



MO 
SERVICE 



MO MESSAGE WITH ANTI-SPAM CHECK UNSUCCESSFUL 



DeliverJiM(service_type, 



AS_Check(sen 
source_addr 



icejype, 

) 



>ource_addr...) 



AS_Check_Reb p(status=deny.[.) 
Deliver_SM_Res p('service denidd'...) 



Update(service 
destination 



add 



Update.RespQ 



SMDPP(TID, 



,bearer data...) 



type. 

r...) 
atus...) 



smdppO 



MO 
SERVICE 




ROUTE MESSAGE TO 
DESTINATION ESME 



RECEIVE RESPONSE FROM 
DESTINATION ESME 



524 



526 



SEND RESPONSE TO 
ORIGINATING MC 



/"WAIT FOR NEXT 528 
V MO MESSAGE / 



FIG, 1 5 



14/17 



GENERAL CANCEL 



CANCEL 
SINGLE 
MESSAGE 



CANCEL 

ALL 
MESSAGES 

BY 
SERVICE 
AND 
DESTINATION 
ADDRESS 



ESME' 




SMPP GATEWAY 




MC 




S.T.P. 



228 



CANCEL SINGLE MESSAGE 



CanceLSM(messageJcl...) 

CanceLSM(meisage_icl...) 



Cancel_SM_Re:;p(...) 



Cancel_SM_Re>p(...) 



CANCEL MULTIPLE MESSAGES 



Cancel_SM(service_type, 
destination.address...) 



CanceLSM_Re5p(...) 



Cancel_SM(ser/iceJype, 
destination_a(ldress...) 



CanceLSM_Rejp(...) 



FIG, 1 6 



GENERAL REPUCE 
202 



ESME 



REPUCE 
SINGLE 
MESSAGE 



SMPP GATEWAY 



111 



Replace_SM(m^ssageJd...) 

Replace_SM(me|ssage_id...) 



Replace_SM_R{sp(...) 



MC 



-A 



224X 



Replace_SM_Resp(...) 



S.T.P. 



228 



FIG. 1 7 



15/17 



GENERAL-ENQUIRE LINK 
202 



ESME 



222 



SMPP GATEWAY 



Enquire_Link(.. 



Enquire_Link_Resp(...) 



a224x r 



228 



MC 



) 



Eiiquire_Lirik(. 



Enquire_Link_Resp(...) 



S.T.P. 



) 



FIG, 1 8 



GENERAL ALERT NOTIFICATION 
202 



ESME 



MT 
SERVICE 



SMPP GATEWAY 



y-222 rlUt r 



228 



Data_SM(servicBjype, 
destination_ad((r, seLdpf...) 

Data_SM(servic 



Data_SM_Resp(|message_id 
dpf_result...) 



MC 



destinQtion_ad c r, seLdpf...) 

Dafa_SM_Resp()TiessageJd, 
dpLresult...) 



S.T.P. 



!_type, 



MS NOT AVAILAB 



SUCCESSFUL MESSAGE D 



LIVERY 



Alert_Notificatl(ln(source_addre|ss 
esme_addr...) 



Alert_Notificati(in(source_addr4ss, 
esme_addr...) 



FIG. 1 9 



16/17 



ACTIVATION 228 

^ 

SWITCH MANAGER SMPP GATEWAY MC 



^222 ^224x r 



228 



S.T.P. 



226 



HLR 



MSG 



232 



lOAA 



Submit_SM( 
short_mess|age 



setivicejype, 
...) 

Submit_SM( 
short_messpge 



Submit_SM_Resp{messageJd 



ser|/ice_type, 

...) 

Submit_SM_R6!sp(messageJd 



) 



R 



GNOT(activation 



regnot(...) 



smclpp(...) 



smclpp(...) 



SMDPP(NAM download...) 



SMDPP(NAM c 



min,ESN,..) 



)mmit...) 



ROAA 



Submit_SM(ser|vice_type 
short_mes^age...) 

Submit_SM(service 
short 



Submit_SM_Resp(messageJd 



icejype, 
_messpge...) 

Subnnit_SM_R^sp(messageJd...) 
) 

SMSREQ(MIN.|.) 



SMSREQ(SMSAddr...) 



SMDPP(NAM do 



smdpp(...) 



SMDPP(NAM commit...) 
smdpp{...) 



REGNOT(MIN, ESN...) 



wnload...) 



regnot(...) 



17/17 



FIG. 20 



202 



m ESMEs m 



4 



202 



m ESMEs ^ 



202 



fc6666 



^ ESMEs ^ 



222 
A. 




SMPP GATEWAY 
252 



CISCO 



256 



LOCAL DIRECTOR 
258 s 



420 



SEC 



260 



CISCO 



LOCAL DIRECTOR 



PR! 



1 



254 



420 



SEC 




262 



264i^ 



ROUTING 
NODE - 1 

SUN 
NETRA t- 
14000 



ROUTING 
NODE - 1 

SUN 
NETRA t- 
14000 



264N 











MESSAGE 
CENTERS 



MESSAGE 
CENTERS 

224i 



MESSAGE 
CENTERS 

2242 



224 X 



PTO/SB/01 MODIFIED BY AT&T CORP. 



DECLARATION FOR 
UTILITY OR DESIGN 
PATENT APPLICATION 


Attorney Docket Number 


2000-a474D 


First Named Inventor 


Thomass^ Cais^t 


COMPLETE, F KNOWN 


Declaration □ Declaration 


Application Number 




Submitted OR submitted after 
with Initial Initial Filing 


Filing Date 




Filing 


Group Art Unit 






Examiner Name 





As a below named inventor, 1 hereby declare that: 

My residence, post office address, and citizenship are as stated below next to my name. 

i believe I am the original, first and sole inventor(if only one name Is listed below) or an original, first and joint inventor (if plural names are listed below) of the 
subject matter which is claimed and for which a patent is sought on the invention entitled: 



A System And Method For Performing Throttle Control In A SMPP Gateway 



(Title of invention) 

the specification of which 

[y1 is attached hereto 
p OR 

[J. was filed on as United States Application Number or PCT International 

\,i Application Number and was amended on (if applicable). 

I fliireby state that I have reviewed and understand the contents of the above identified specification, including the claims, as amended by any amendment 
sp^ifically referred to above. 

I adicnowledge the duty to disclose information which is material to patentability as defined in Title 37 Code of Federal Regulations,§ 1.56. 

I ptereby claim foreign priority benefits under Title 35, United States Code § 119 {a)-(d) or § 365(b) of any foreign application(s) for patent or inventor's 
c^Mficate, or § 365(a) of any PCT international application which designated at least one country other than the United States of America, listed below and 
have also identified below, by checking the box, any foreign application for patent or inventor's certificate, or of any PCT international application having a 
fifeg date before that of an application on which priority is claimed. 



L^Prlor Foreign Application 
Number(s) 


Country 


Foreign Filing 

Date 
(MM/DD/YYYY) 


Priority 

Not 
Claimed 


Certified Copy 
Attached? 

YES NO 








□ 


□ □ 








□ 


□ □ 








□ 


□ □ 








□ 


□ □ 



[~| Additional foreign application numbers are listed on a supplemental priority data sheet PTO/SB/02B attached hereto 



I hereby claim the benefit under 35 U.S.C. 11 9(e) of any United States provisional application(s) below. 



Application Number(s) 



Filing Date{ MM/DD/YYYY) 



I I Additional provisional application numbers are listed on a 
supplemental priority data sheet PTO/SB/02B attached hereto 



SEND TO: Assistant Commissioner for Patents, Box Patent Application, Washington, D.C, 20231 



PTO/SB/01 MODIFIED BY AT&T CORP. 



Attorney Docket Number: 2000-0474D 



DECLARATION - Utility or Design Patent Application 



I hereby claim the benefit under 35 U.S.C. 120 of any United States application(s), or 365(c) of any PCT international application designating the United States of America, listed 
below and, insofar as the subject matter of each of the claims of this application is not disclosed in the prior United States or PCT International application in the manner provided 
by the first paragraph of 35 U.S.C. 112, 1 acknowledge the duty to disclose information which is material to patentability as defined in 37 C.F.R. 1.56 which became available 
between the filing date of the prior application and the national or PCT International filing date of this application. 



U.S. Parent Application or PCT Parent 
Number 



Parent Filing Date 
(MM/DDA^TYY) 



Parent Patent Number 

Qf applicable) 



I I Additional U.S. or PCT International application numbers are listed on a supplemental priority data sheet PTO/SB/02B attached hereto. 



As a named Inventor, I hereby appoint the following registered practltioner(s) with full power of substitution and revocation, to prosecute this application, to 
mal(e alterations and amendments therein, to receive the patent, and to transact all business in the Patent and Trademark Office connected therewith: ' 



I I Customer Number 
OR 

^ Registered practitioner(s) name/registration number listed below 



Place Customer Number Bar 
Code Label here 



Name 



Registration 
Number 



Name 



Registration 
Number 



CCJTOVER, Michele L. 
nfrpRETSKY, Samuel H. 
iJI^CSON, Thomas M. 
liwY, Robert B. 
lyftjKA, Gary H. 



34962 
27873 
44166 
28234 
35290 



DELACRUZ, Cedric G 
GARG, Rohini K 
LEE, Benjamin S. 
MCGAHAN, Susan E. 
NAVON, Jeffrey M 



36498 
45272 
42787 
35948 
32711 



I also appoint the following additional registered practitioner(s) named on the Registered Practitioner Information (Supplemental Sheet) (PTO/SB/02C modified by AT&T 
Corp.) attached hereto with full power of substitution and revocation, to prosecute this application, to make alterations and amendments therein, to receive the patent, and to 
transact all business in the Patent and Trademark OfRce connected therewith. 



Direct all Correspondence to: 



□ Customer Number or Bar Code Label 



(Insert Customer No. or Attach bar code label here) 



or 



Correspondence address below 



tmnB 



Samuel H. Dworetsky 



MfDRESS 



AT&T CORP. P.O. Box 4110 



CITY 



Middle town 



STATE 



New Jersey 



ZIP CODE 



07748-4110 



COUNTRY 



United States of America 



FAX 



732-368-6932 



I hereby declare that all statements made herein of my own knowledge are true and that all statements made on Information and belief are believed to be true; and further that 
these statements were made with the knowledge that willful false statements and the like so made are punishable by fine or imprisonment, or both, under 18 U.S.C. 1001 and that 
su6h willful false statements may jeopardize the validity of the application or any patent issued thereon. 



Name of Sole or First inventor 



□ A petition has been filed for this unsigned inventor 



Name 


Thoma^^^pasJ: 


Signature 


^-<^^:>C^ ' Date ^--^^^^cJ 


Citizenship 


United StaterJ^ " 


Address (line 1) 


N.E. 136th Street 


Address (line 2) 


Redmond 


Address (line 3) 


King County 


Address (line 4) 


Washington 


Address (line 5) 


USA 


Zip Code 


98033 



Additional Inveriiors are being named on the 1 seperately numbered sheets attached hereto 



SEND TO: Assistant Comnnissloner for Patents, Box Patent Application, Washington, DC 20231 



PTO/SB/02A MODIFIED BY AT&T CORP. 



Attorney Docket Number: 2000-0474D 



DECLARATION 


ADDITIONAL INVENTOR(S) 
Supplemental Sheet 
Page 1 of 1 


Name of Additional Joint Inventor, If any: 


□ A pel 


tition has been filed for this unsigned inventor 


Name 


I^vid Midkif f ^ 


Signature 




Date 




oiiizensnip 


United States 


Address (line 1) 


8105 NE 128th St. 


Address (line 2) 


Kirkland 


Address (line 3) 


King County 


Address (line 4) 


Washington 


Address (line 5) 


USA 


Zip Code 


98034 


Name of Additional Joint Inventor, if any: 


□ A petition lias been filed for this unsigned inventor 


Name 




Signature 




Date 




Citizenship 




Address (line 1) 




Address (line 2) 




)lfidress (line 3) 




^dress (line 4) 




ifddress (line 5) 




0 Zip Code 




Nidtie of Additional Joint Inventor, if any: 


□ A petition has been filed for this unsigned inventor 


Name 




Signature 




Date 




M: Citizenship 




^dress (line 1) 




^dress (tine 2) 




iSddress (line 3) 




Address (line 4) 




Address (line 5) 




Zip Code 




N&me of Additional Joint Inventor, if any: □ A petition lias been filed for this unsigned inventor 


Name 




Signature 




Date 




Citizenship 




Address (line 1) 




Address (line 2) 




Address (line 3) 




Address (line 4) 




Address (line 5) 




Zip Code 





SEND TO: Assistant Commissioner for Patents, Box Patent Application, Washington, DC 20231 



PTO/SB/02C MODIFIED BY AT&T CORP. 



Attorney Docket Number: 2000-0474D 



DECLARATION 


Registered Practitioner 

Information 
(Supplemental Sheet) 


Name 


Registration 
Number 


Name 


Registration 
Number 


RESTAINO, Thomas A. 

4^. J. ■ 


33444 


STEINMET2, Alfred G. 


22971 



SEND TO: Assistant Commissioner for Patents, Box Patent Application, Wasliington, DC 20231 



